Re: [FAQ?] Rationale for git's way to manage the index
- From
Petr Baudis <pasky@suse.cz>
- Date
- May 9, 2007, 13:41 UTC
- Message-ID
- <20070509134151.GT4489@pasky.or.cz>
- In-Reply-To
- <alpine.LFD.0.98.0705072137450.3974@woody.linux-foundation.org>
On Tue, May 08, 2007 at 06:45:32AM CEST, Linus Torvalds wrote:
Show 12 quoted lines
> 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