Re: [FAQ?] Rationale for git's way to manage the index

[Petr Baudis <pasky@suse.cz>]

On Tue, May 08, 2007 at 06:45:32AM CEST, Linus Torvalds wrote:
> 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).

Hmm, does this really work so well for you guys? Because thanks to Mr.
Murphy, in my case, when I have some custom Makefile tweak, I always
need to commit some unrelated changes involving Makefile more often than
usual, and so on; so in general case, file-level changes exclusion
doesn't really work so well for me.

So this use of index seems to me really as a workaround for more
fine-grained change control (in a similar way that rename following
would be a workaround for lack of more fine-grained content moves
tracking). I will have to look into git-gui's hunk-level control and
maybe reimplement it in tig.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Ever try. Ever fail. No matter. // Try again. Fail again. Fail better.
		-- Samuel Beckett