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 - 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
