Re: Two ideas for improving git's user interface

From: Linus Torvalds <torvalds@osdl.org>
Date: Feb 2, 2006, 01:44 UTC
Message-ID: <Pine.LNX.4.64.0602011732560.21884@g5.osdl.org>
In-Reply-To: <Pine.LNX.4.64.0602011656130.21884@g5.osdl.org>

On Wed, 1 Feb 2006, Linus Torvalds wrote:

Show 5 quoted lines

> 
> And notice how I commit the _merge_ without actually committing my dirty 
> state in the tree - and whether the files involved in my standard dirty 
> changes ("Makefile") are part of the state that the merge changed or not 
> is _totally_ irrelevant.

If you get the feeling that merging is special, then to some degree, yes, you'd be right.

Merging (especially with conflicts) is the _one_ operation where you absolutely have to know about the index. If you don't know about how the index works, you can get the conflict resolution right kind of by accident, simply because the default workflow of

	.. edit conflict to look ok ..
	git commit file/with/conflict

actually happens to do exactly the right thing (very much on purpose, btw), but the fact is, to actually figure out more complicated conflicts and to _understand_ what happens, you absolutely need to be aware of the index. Not being aware of it just isn't an option for any serious git user.

(Btw, I think this is where cogito falls down. Cogito tries to hide the index file, but I don't think you really _can_ hide the index file and also do merges well at the same time. Anybody who has non-trivial merges should use raw git - not just because the "recursive" strategy just works better, but exactly because of the index file issue).

So when you work with a merge, the index file content really in a very real way _is_ the merge. Yes, the index file is also technically how git actually does all the merging complexity, but in this case, there also is no "diff" to the parent, and the number of changed files may be in the hundreds, yet "git diff" should be basically empty when you finally commit your merge.

I say "basically empty", because as I've explained, at least I personally have had dirty state in my tree at the time I commit a merge - on _top_ of (and independently of) the state that I actually commit.

So to recap:

 - you really do have to be aware of the index file at some point. Trying 
   to hide it entirely is a huge mistake.

 - real git power users _will_ use their awareness of the index file when 
   they commit. You will too, some day. Maybe it's only for merges, but I 
   wouldn't be surprised if somebody at some point wants to take advantage 
   of it even for "normal" working conditions (ie use "git-update-index" 
   to "freeze" a certain state for committing, and then editing the file 
   and _not_ committing those edits)

So making "-a" the default would be just a horrid horrid mistake. You can only hide the index so far - don't even try to hide it more.

			Linus