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 ...

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 -

Well, sure. It could be an argument to git-add. But surely not the default? git-add --latest maybe? Nicolas -

Hi, I fear that this is just your being used to the CVS mindset. Please see http://article.gmane.org/gmane.comp.version-control.git/32792 for details. Hth, Dscho -

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 ...

While this certainly matches the git model better than just automatically taking whatever state exist at commit time (you instead introduce it as a special "empty state" case), I don't think you really want it. Why? Two reasons: - you're still left with all the same issues (ie you do need to use "git commit -a" because that is simply fundamental, and if you don't, "git commit" now causes an ERROR, which is just illogical - you just added the data!) So it's ...

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 -

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

>

git stage ? -

I disagree. "add" is beautiful. It is short, easy to remember, and transcend pretty much what the index is all about. And just because "add" and "edited" can be made into the same command is a pretty damn good reason not to create a separate command. You "add" changes to the changeset then you commit that changeset. No need to care whether or not this is a new file, an edited file, etc. Nicolas -

Sure. ;-) Nicolas -

I'm happy with the direction of having several commands that take the place of update-index, each with its own name oriented toward what the user wants to do. Obviously, "add", "mv", and "rm" have obvious places where the user wants to use them. There's the merge case where "resolve" and "resolved" have both been floated as possible names. It might even make sense to invent one more name for the case where the user wants to inform git that a file has been edited and that git should ...

Actually, the .keep file is simply not removed as it should. But first it appears that commit f64d7fd2 added an && on line 431 of git-fetch.sh and that cannot be right. There is simply no condition for not removing the lock file. It must be removed regardless if the previous command succeeded or not. Junio? Now for the actual problem. I instrumented git-fetch.sh to understand what's going on as follows: diff --git a/git-fetch.sh b/git-fetch.sh index 8365785..042040e 100755 --- ...

Yes. There is a logical explanation for what git does, and it is self-consistent. It just means that the user is _forced_ to pass file state across the: "working tree" -> git boundary at two different times with two different commands for the very first commit the user makes. And the user _must_ understand that this is a two-step process, (even though, without the "typo" in my example above it would be natural to conclude the transition occurred only during "commit"). See? Git _is_ ...

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 ...

> "Maybe we could do git-commit -a

In the headers or in the message body? StGIT adds this line automatically in the message body (and recently only if the sender is different from the patch author but the templates are flexible and can be changed). -- Catalin -

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 -

Right now you only have commits of the top directory aka the super project. Every subdirectory is just that: a directory (which git stores as trees). Now, if you have a subdirectory that git stores as a commit, not a tree, you have a subproject. It is a directory with history, and because the No, it is not. Currently, there is no way to store a commit within the Here comes the part where we did not meet before. Of course you do not make any reference from your subproject to ...

But you have got the submodule on your local disk anyway. So just setup It works as it always works in git: The supermodule commit contains the submodule commit, the submodule commit contains the submodule files, so the supermodule contains the submodule (at least the part of the submodule that is visible). It _must_ be one repository but it need not Again I do not see the problem. Probably I have a much simpler picture of submodules: They are just commits in the supermodule's tree. ...

It's not so much an actual commit, as a reference to a commit in another repository. Andy -- Dr Andrew Parkins, M Eng (Hons), AMIEE andyparkins@gmail.com -

Not entirely, although I think it's going to be handy for submodules. It was in a thread about remotes branches. By allowing checkout of any commit rather than only those that have a ref/heads/ entry, you effectively have a read-only checkout. You obviously couldn't commit to a repository like this, because HEAD wouldn't point at anything that is changeable. It would be very easy to just git-branch from there and start work though. I think it's going to be necessary for the submodule ...

I believe that Andy meant "development history" in his above scentence. Naturally, using the code from the submodule while being capable of developing the submodule separately from the supermodule is what It has? We're not talking supermodule specific things anymore, are we? -- Andreas Ericsson andreas.ericsson@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 -

Well, if it is VISUAL editor, you would see this. But adding this to template is certainly good idea. -- Jakub Narebski Warsaw, Poland ShadeHawk on #git -

Hi, Only that you would not see it (or ignore it, as has been illustrated in another thread), because your editor pops up, hiding that message. Ciao, Dscho -

Could we add suggestion by Andreas Ericsson to print in the "smart commit" case: Nothing to commit but changes in working tree. Assuming 'git commit -a' or something like that? -- Jakub Narebski Warsaw, Poland ShadeHawk on #git -

Raimund Bauer offered this suggestion (paraphrased): "Maybe we could do git-commit -a _only_ if the index matches HEAD, and otherwise keep current behavior? So people who don't care about the index won't get tripped up, and when you do have a dirty index, you get told about it?" Johannes Schindelin pointed out that this isn't the right thing to do for an --amend, so that is checked for. Additionally, it's probably not the right thing to do if any files are specified with "--only" ...

For those using emacsclient, I don't think ^C will work. Is there another way to undu an ammend commit? If not, is there any sense in detecting a magic comment to abort the ammend commit? -

By the way, I think that git-commit should also watch the return code from the editor, so you can ^C it to abort git-commit --amend. -- Jakub Narebski Warsaw, Poland ShadeHawk on #git -

I can't use git-cvsserver because the main repository is going to have to stay on CVS for the time being. I don't think it could be used as a drop in replacement for our existing server anyway as it doesn't support tagging or branching. Using git is my own personal indulgence (At least until I can demonstrate it's worth while the other migrating ;-). It looks like git-svn is the sort of tool I'd want for CVS although I'm not sure how it would live with our CVS branched development model. ...

Raimund Bauer offered this suggestion (paraphrased): "Maybe we could do git-commit -a _only_ if the index matches HEAD, and otherwise keep current behavior? So people who don't care about the index won't get tripped up, and when you do have a dirty index, you get told about it?" Johannes Schindelin pointed out that this isn't the right thing to do for an --amend, so that is checked for. Additionally, it's probably not the right thing to do if any files are specified with "--only" or ...

Hi, I'm trying to get a setup where I can use git for my day to day coding on problems but still mirror a CVS repo. The situation is muddied slightly by the way we manage changes in our CVS repository and baselines. The CVS manner of working means we create a branch at a given point to do work on it: BL1_CH2 / / BL1_CH1 BL1---/ And then in the meantime a new baseline may be released: BL2 BL1_CH2 | / | BL1_CH1 BL1--/ So we employ ...

'git diff --cached' still works, but its use is discouraged in the documentation. 'git diff --index' does the same thing and is consistent with how 'git apply --index' works. Signed-off-by: Andreas Ericsson <ae@op5.se> --- Documentation/git-diff.txt | 6 ++++-- builtin-diff.c | 2 +- 2 files changed, 5 insertions(+), 3 deletions(-) diff --git a/Documentation/git-diff.txt b/Documentation/git-diff.txt index 228c4d9..3144864 100644 --- a/Documentation/git-diff.txt +++ ...

I am serious about that. I haven't thought of it as an independent command/program though. Can you implement givor exactly like the above Okay now joke part. This command name is better :-D $ git commit [...] nothing to commit $ dammit $ git commit Givor: You haven't marked any file for commit using "git-update-index <file>" Givor: and you didn't provide files to commit with "git commit <file>" Givor: so I assume that you wanted to commit all changed files Givor: You can use "git commit ...

The fact that git has previously used symbolic links for representing symbolic refs doesn't seem relevant to the current function of git-symbolic-ref. This patch makes less of a big deal about the symbolic link history and instead focuses on what git does now. Signed-off-by: Andy Parkins <andyparkins@gmail.com> --- I've not been using git long enough to have ever experienced the symbolic-link refs. It seems unnecessary that the man pages talk about something that doesn't happen in such ...

Hi, If you are talking about "git commit file1 file2" ignoring the current index, and building a new index just updating file1 and file2 from the working directory, I disagree that it was a big mistake. Actually, I was very happy to get that change (IIRC it was me requesting it, so blame me), because I now can say: just specify exactly what you want to commit *1*. If you want to commit just file2 (even if you added file1, but did not commit it yet) do "git commit file2". If you want ...

By the way, short option -i is not --index but --include (i.e. commit both changes in index and files mentioned on command line). Perhaps -I? -- Jakub Narebski Warsaw, Poland ShadeHawk on #git -

Actually gitweb uses uid/user the repository (the $GIT_DIR), unless you provide it with an index file. The simplest way is to click on "TXT" link in projects list page, save it somewhere, edit it, and recompile gitweb with this file as GITWEB_LIST (see README): make ... GITWEB_LIST=<index> gitweb/gitweb.cgi (or just edit gitweb.cgi or gitweb_conf.perl setting $projects_list to this file). Perhaps gitweb should use user.name from the repository instead... P.S. Please reply also to git ...

Hi, I'm new to git. Just got everything setup and imported a new project. From gitweb it says that my git project's owner is: Unprivileged User Should I be worried about this when I begin using this git project with others? How would I resolve this, to make the owner as the name I set in my ~/.gitconfig, or is there something I didn't read in the docs? Thanks, beside this small glitch, git has been great. Ed. -

Yes. We don't have that as a commit. The commit history starts with You can't check it out, since it's not a commit, but since it is a tree, you can: - use it as a base for "git diff" git diff v2.6.11 <any-commit-goes-here> - or if you want to use it as a base for development, create a new commit and branch from it: git-commit-tree v2.6.11 <<EOF This is an initial commit starting at the state of Linux-v2.6.11 EOF and then you can take the resulting SHA1 (that ...

This looks very appealing to me. I know I've often been frustrated when git refuses to fast-forward just because I have dirty state, (and stashing the diff manually into a patch file, then re-applying it after fast forward is really annoying---getting work done in spite of As I said above it seems very reasonable to me. As for the problem you mention here, isn't "no good way to recover from it" the real problem, and not this merge possibility? And is there enough information in the index file ...

Great. But let me repeat my last question: Would it make sense for "git add" to do the same as "git update-index" on already tracked files? Given the explanation above this would make 100% sense to me. Even for newbies this might help them understand the power of the index with only one command. "You _add_ your changes together before you may commit." That's simple to understand even for newbies. And then they'll start using the power of the index even without realizing it. But ...

Wonderful! We might be converging to something then. Because, conceptually, it then becomes much easier to tell newbies about the index as follows (this could be pasted in a tutorial somewhere): Contrary to other SCMs, with GIT you have to explicitly "add" all the changes you want to commit together. This can be done in a few different ways: 1) By using "git add <file_spec...>" This can be performed multiple times before a commit. Note that this is not only for ...

Yup. And it appears that we even agree that "intent to add" is I sense that you are inviting me to argue for reverting the other "git commit" braindead which is spelled "--only" (and Other than these "twists", I think it makes sense, and that is what I think. But making sense to me does not necessarily validate that a tutorial document is great for its intended audience, since I lost git virginity long time ago. I can only endorse that the description is technically accurate. -

By the way, I think I've said all I can in this thread. If the "create file; git add; edit file; git commit" confusion isn't blisteringly obvious to the git maintainers then I think I have to give up here. And this isn't just CVS-induced brain damage. It's the user being required to mentally juggle 3 states for the file, (the last "committed" state, the current "working tree" state, and this "something else" state). The sequence above, (which is very natural), exposes this "something else" ...

If you want to ignore the index, you'd always use "git commit -a". The old argument by incredulity. The fact that you cannot see it doesnt' change the fact that I use it all the time. Usually not for the same file, but committing something that is different in the index and in the working tree is my normal behaviour - it's how any number of things work (like merging while you have dirty state, or applying patches while you have changes). So, let me condense the argument: - ...

Hi, An obvious deficiency would also be the presence of hundreds of debug quirks I had to introduce to find the bug which I finally fixed. But I do not want to commit, because it is such a mess. So: into the index, ye files. Now I can clean up everything I introduced to find the bug. If the result does not work as expected? "git diff"! But now that I cleaned up the mess, I find that there is a more elegant way to solve the problem. Into the index, ye files! Clicketyclick, if I ...

I actually really like the current defaults for "git commit". And I say that despite the fact that the defaults are _different_ from the original ones. I like the fact that when you do "git commit filename", it really will commit _only_ that file, not the other files you added. It's logical. So you can do echo a > file-a echo b > file-b git add file-a file-b git commit file-a and it will only commit one of them. Now, admittedly, the status message that you get is ...

Sure. It's just that some people seem to expect the index to be different from HEAD, and are afraid of being "confused" by it. The fear seems to be about "git diff" getting different results from "git diff HEAD", and always having to _check_ the two. So I wanted to make it clear that I never have that situation, because I never leave the index "dirty". I agree that there is nothing odd about it, but I think that people who don't actively use the index (or don't use git at all, and ...

But, wait a second. What if I do my typo fix to file-a in between that "git add" and the "git commit". Why should "git commit" insist so vehemently on committing the _old_ state of file-a while "git commit file-a" so happily commits the _new_ state? I'm really not seeing conceptual consistency to what "commit <files>" does compared to "commit". The "commit <files>" case is a special-case of "commit -a" while "commit" is just plain different. See? I do like the direction Nico is going ...

Well, sure, because the documentation *talks* about it as a separate entity all its own. Just look at the man page for git-diff as a great example of this, or the ascii art diagram of the index. It is all But then why is the default for "git commit" to commit the index, if the index is almost == HEAD? And why is git-update-index given such If everyone agrees with this, I think it would be easier to make changes to the documentation and maybe some UI tweaks about what the default might ...

I'm sorry, Linus. I'm really failing to communicate with you somehow here. I _do_ use this all the time too. I don't need you to explain it to me again. I get it, I like it, I use it. That's not at all what I'm Nope. I get it and I use it. Most commonly I do things like "update-index;commit" to separate independent changes, (I could use "git commit explicit/files" instead but I *gasp* actually enjoy being able to manually stage things in the index first). What I'm trying to say is that ...

OK. I'll try to not mention the "index" any more in any postings here. And can we agree that any time git spits out a message directing the I think the response that would come from the people that are confused is: "But I told git I wanted to track this file when I said 'git add' long ago. Why is it making me tell it again." As you mentioned, all systems have _some_ mechanism for keeping track of the files to be committed, (and git's is only unique in having a name and providing ...

Might it be a good idea to have "git-add" do the same as "git-update-index" on already tracked files? That could be easily taught as "you must explicitly _add_ files to your next commit" and whether the file is already tracked or not wouldn't matter. This would help newbies actually getting used the index without mentioning the dreaded word "index" at all. Right now git-add on an already tracked file does nothing, not even a message to say it did nothing. Nicolas -

Sure. There's no need to lie to about how things work. And I agree that would cause later problems. As far as getting the message out, we have several different ways to do that: 1. In-person presentations, demos, tutorials 2. Written tutorials 3. Reference documentation 4. Output from git commands 5. The default behavior of git commands And that list is roughly sorted from most to least "information bandwidth". The limited bandwidth at the bottom-most levels in my list, ...

So I will add my $0.02: Summary: leave git-commit as-is I think the intimidation factor of the index is overstated. A scratch working area is a natural concept -- that's what people do who don't even _know_ what an scm is. I agree with Junio's description of commit -a as default breaking the mental model. I've played with three distributed scm: tla, hg, and git. I've stuck with git because, in part, it helped me to learn its more advanced features -- not because it was ...

Plus, one assumes, the git-generated comments in the commit message will tell you what kind of commit it has decided to do. I like this suggestion a lot. Thinking back over my git usage recently, which has included both styles of commits (though mostly -a ones), I think this would have done the right thing by default in every case. -Steve -

I have been(silently) following the git commit discussion and started being fully on the side of git commit -a being the default, but was slowly moving over towards the git commit -i being the default camp. This post seems like a Eureka moment - chew over the problem long enough and someone comes in from left field with an off the wall remark that suddenly clarifies everything. -- Alan Chandler http://www.chandlerfamily.org.uk -

Unless you do "git update-index" (and thus are already using the index) on any files, "git diff" shows you exactly the changes between your last commit and the working tree. There's nothing magic, odd or confusing about it, no matter which scm you come from. -- Andreas Ericsson andreas.ericsson@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 -

Sounds sane. Especially if we couple it with a hint for the user to use "commit -a" when he/she wants to do blanket commits. So in essence that would mean: If no pathspecs are given and index matches current HEAD, print out "Nothing to commit but changes in working tree. Assuming 'git commit -a' and then act accordingly. Carl, do you think that would satisfy the desires of your RedHat peers? Always doing '-a' by default is terribly wrong for those of us who actually use partial commits a ...

Hi, See git-gui from Shawn. It should really help new users with a graphical user interface. Ciao, Dscho -

Hi, So many people spoke for it, it's time I crash the wedding. From a usability viewpoint, it is a horrible convention. The user has to remember too much of the side effects to handle the commit operation. The function of the program would no longer be dependent on the command line arguments and your config, but _also_ on something as volatile as the index. You would literally end up asking "did I change the index?" _everytime_ before you commit. And remember, even a simple "git ...

Andy Parkins wrote: So what? You have a submodule commit that only exists in the supermodule. I fail to see the problem. The changes you made to the submodule _in the supermodule_ can later be pulled from wherever you want. Regards Stephan -

hoi :) What about: You decide to try something out quickly and create a new branch in the submodule. After you have verified that it works, you merge it to the submodules master branch and commit that to the supermodule. Not that complicated, isn't it? In fact, my current implementation does not even allow to change the Please excuse that I am not an native english speaker and I may have That is exactly what I wanted to say. In the supermoduel you call update-index (with the submodule ...

If you have no commit message the commit will be aborted. So just write back a completly empty commit message. "dG:wq" in vi land. apw@larry:~/git/linux-2.6$ git commit --amend * no commit message? aborting commit. apw@larry:~/git/linux-2.6$ -apw -

I see how it is! :-) When Shawn says it, it is to be liked. But when I allude to it a _year_ ago, I'm ignored. From: Jon Loeliger <jdl@freescale.com> To: git@vger.kernel.org Subject: Re: Trying to Update All Heads of a Repository Date: Fri, 4 Nov 2005 07:49:40 -0700 Message-ID: <E1EY2su-0006LW-IN@jdl.com> So, from the git-pull man page: For "git push", the local ref that matches <src> is used to fast forward the remote ref that matches ...

Doesn't one of our existing t/ scripts do that? -

Currently tutorial.txt doesn't work like that--there are places where it just tells the user to edit a file, or make a few commits, without listing commands to do so. It also isn't linear. That could all be "fixed", but I think the result would just make it more tedious. But I agree that a "git tutorial" command to set up a canonical example repository might be fun. --b. -

I'm very happy my stupidity could help. ;-) On a related note ... I do think that bzr has quite an intuitive set of commands, and it is easy to learn, though at this point I don't feel git is really *that* much more difficult in itself. Although the terminal output for some problems could be improved, most of my difficulties are stemming from overlap of command names when the commands themselves do different things, and the fact that git's documentation is somewhat more technical than ...

Right now (and in the near future), nope. "git blame" will track the changes (so the pure movement wasn't just an addition of new code, but you'll see it track it all the way down to the original), but "git merge" is still file-based. In other words, "git merge" does uses a data similarity analysis that could be used for smaller chunks than a whole file, but at least for now it does it on a file granularity only (and then passes it off to the standard RCS three-way merge on a ...

Here's a crazy idea. How about a "git tutorial" builtin or "git example" or something that would create a repository into some useful state for demonstrating something. I know that I'm regularly putting stuff into emails like: mkdir gittest cd gittest git init-db echo hello > hello git add hello git commit -m "add hello" git checkout -b other echo other > other git add other git commit -m "add other" git checkout master # OK, that was just setup, here's what I want to ...