On 5/8/07, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
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).
Totally, when merging git's approach is incredibly useful. gitk --merge and the resolved conflicts not appearing in the default git diff is great stuff. For for small, simpleminded and mostly-linear development it's not that important. Of course, I use git on projects large and small, so I can understand it. For someone using it with a small mostly-linear project, the whole index thing is overkill, and the explanations pointless. I can understand people wondering WTF.
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.
On a large project it's always a good idea to commit with explicit paths -- regardless of your SCM. As it happens, I have to use explicit paths with CVS, or it'll punish me by taking solid minutes to do a 2 file commit. I am sure that the mozilla and OpenOffice developers using CVS also commit with explicit paths. Life's too short to waste an hour. (The times are from working on Moodle, hosted on SF.net with ~4K files, 700 directories.). cheers, m - 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