Re: Two ideas for improving git's user interface

[Linus Torvalds <torvalds@osdl.org>]

On Wed, 1 Feb 2006, Linus Torvalds wrote:
> 
> 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