Anyone have a nice script for suppressing diffs caused by CVS keyword expansion when someone checked the kernel sources into CVS? I have 200,000 lines of various forms of this mixed in with real changes It is unclear who checked it into CVS, Microcross or Arch Linux. If it is Arch Linux finding the source for their 2.6.11.4-1 release would help a lot. I looked on their web site and couldn't locate it. I'm starting understand why the support for MX21 on a CSB535FS has never been added to the mai...

So, in short, -i is easier to explain, but is also least used. Perhaps also because one can simply update index with <files> before git commit instead of doing "git commit -i <files>". -- Jakub Narebski Warsaw, Poland ShadeHawk on #git -

Hi, I think this is so important, that I vote for including this email as Documentation/howto/explain-why-git-is-better-than-cvs.txt Ciao, Dscho -

Still, perhaps (perhaps!) it would be useful to have "intent to add" git-add. -- Jakub Narebski Warsaw, Poland ShadeHawk on #git -

One thing that I think is non-intuitive to a lot of users (either novice or who just don't do it much) is that it matters where in the process you do "git add <path>" if you're also changing the file. Even if you understand the index, you may not realize (or may not have internalized the fact) that what git-add does is update the index with what's there now. I think the more obvious behavior is to have it record the fact that you want to have the path tracked, but require one of the usu...

I'm not sure I want to see the whole added file more when diffing two trees, or when I do "git diff --cached" after "git update-index --add", than when I do "git diff" after "git add", but I'll concede that viewing the content of a new file as a diff is no fun. (Maybe diff-against-nothing for display needs work in general? It's solve the whole root commit thing, This is where I think "git add" is really broken. For every other git command, if the command causes the index to not match HEAD, t...

And actually I think this is a good thing. This is what makes the index worth it. Better find a way to make it obvious to people what's happening. Nicolas -

Index is accessible, just like committed contents. The fact that gitk, qgit, git-gui doesn't display state of index is their limitation. -- Jakub Narebski Warsaw, Poland ShadeHawk on #git -

>

checkin. You check things into index with "git checkin" and later commit the index with "git commit". -

Hi, I suggest "commit". How about this: after editing the file, you tell git that you finished editing it by doing git commit the-edited-file.txt Hmmm? Ciao, Dscho -

git stage ? -

I actually thought of that. But compared to "refresh" it sounds more like something that suggests marking a file path rather than copying contents, so our dark lord might not approve of the wrong ideas it might allow to persist in brain-damaged heads. It is nice and short, which is a bonus though. -Carl

Hi, ... and suffer another thread a la "pull/merge"? Please no. Ciao, Dscho -

True, but your "echo" patch breaks things even more -- when fast forward check fails, it should cause the entire command should report that with the exit status. That suggests that we need to come up with a way to clean up these .keep files some other way than just being one of the command near the end. As to the mysterious "echo e <empty>" I will not have chance to look at it myself until later today (I'm at work now and it is not my git day today). -

while in git "git add" means "I want to add this file" (in the state it is now) and not "I want the system to 'know' about this file". And "commit" mean "Please commit the current 'known' state of all files (or/and the current state of files I mention here on the comand line)". Yes, this is different than what other SCM do... -- Jakub Narebski Warsaw, Poland ShadeHawk on #git -

Signed-off-by: Peter Baumann <siprbaum@stud.informatik.uni-erlangen.de> --- gitk | 7 +------ 1 files changed, 1 insertions(+), 6 deletions(-) diff --git a/gitk b/gitk index ab383b3..60f8212 100755 --- a/gitk +++ b/gitk @@ -8,12 +8,7 @@ exec wish "$0" -- "$@" # either version 2, or (at your option) any later version. proc gitdir {} { - global env - if {[info exists env(GIT_DIR)]} { - return $env(GIT_DIR) - } else { - return ".git" - } + return [exec git rev-p...

> "Maybe we could do git-commit -a

Hi I'd like to add to all patchs created by "git-format-patch" command the following line: From: xxx.yyy <foo@crazy.com> I took a look to the command options and git's hooks but I don't find a solution to this problem. Is there any tricks to do this ? thanks -- Francis -

Hi Johannes adviced me to use: [format] headers = "Organization: git-foo\n" configuration. And it works both for mail header and message body. thanks -- Francis -

I stupily thought that it couldn't be used to prepend message for the message body. But since it appends the line at the end of mail header, it does the right thing for me. Thanks for your quick answer -- Francis -

How are these commits any different from just having one big repository? If some of the development of the submodule is contained in the supermodule then it's not a submodule anymore. Why bother with all the effort to make a separation between submodule and supermodule and then store the submodule commits in the supermodule. That's not supermodule/submodule git - that's just normal git. Surely the whole point of having submodule's is so that you can take the submodule away. Let me give ...

sf wrote: Sorry, that was supposed to read: followed by a suffix // The :: does not belong in there. -

Well, I know what the commit is /that/ was all that was stored. So I (actually supermodule-git does): cd $DIRECTORY_ASSOCIATED_WITH_SUBMODULE git checkout -f $COMMIT_FROM_SUPERMODULE Obviously, this is grossly simplified. It also requires that HEAD be allowed to be an arbitrary commit rather than a branch, but that's already been generally agreed upon as a good thing. Andy -- Dr Andy Parkins, M Eng (hons), MIEE andyparkins@gmail.com -

Then I have no idea what you are talking about. A commit _contains_ all the history that lead up to that commit, so if you have the commit, then you also have the history. skimo -