On 5/8/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:
quoted text
> 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.

quoted text
> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html