Re: [FAQ?] Rationale for git's way to manage the index
- Date: Mon, 7 May 2007 21:45:32 -0700 (PDT)
- From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
- Subject: Re: [FAQ?] Rationale for git's way to manage the index
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
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