On Tue, 8 May 2007, Martin Langhoff wrote: > > Heh. Making the index very visible makes sense when you are merging, > Linus and Junio are both integrators and spend a lot of time merging. > Hence the default is for git-commit to observe the index. It is definitely true that some of the advantages of the way git does the index really start shinign when merging and you have content conflicts. What we've done to "git diff" really makes things a lot easier (and anybody who hasn't used "gitk --merge" after a content conflict really hasn't realized how *helpful* git is when merging content conflicts). However, in all honesty, while the whole "index for merges" comes from pretty damn early in git history (the whole "stage number" thing appeared on April 15th 2005 - so it was about a week after the first release), it wasn't the original impetus of the way git works. Git used explicit index updates from day 1, even before it did the first merge. It's simply how I've always worked. I tend to have dirty trees, with some random patch in my tree that I do *not* want to commit, because it's just a Makefile update for the next version (to remind me - I've released kernel versions too many times with an old version number, just because I forgot to update the Makefile). Or other things like that - I have small test-patches in my tree that I want to build, but that I don't want to commit, and I end up doing big merges and whole patch-application sequences with such a dirty tree (obviously if the patch or merge wants to change that file, I then need to do something about that dirty state, but it happens surprisingly seldom). So the whole "update stuff to be committed explicitly" ends up _really_ shining during a merge, but it actually is how I do non-merge development too. Linus - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html