Re: Two ideas for improving git's user interface

[Linus Torvalds <torvalds@osdl.org>]

On Wed, 1 Feb 2006, Carl Worth wrote:
> 
> Here's a fundamental question I have, (and thanks to Keith Packard for
> helping me to phrase it):
> 
> 	Is it ever useful (reasonable, desirable) to commit file
> 	contents that differ from the contents of the working
> 	directory?

Yes. I do it all the time.

I tend to have a certain fairly constant set of changes in my working 
tree, namely every time a release is getting closer, I always tend to have 
the "Makefile" already updated for the new version (but not checked in: I 
do that just before I actually tag it, so that the tag will match the 
commit that actually changes the version).

I do that largely for historical reasons, namely that I've forgotten too 
many times to actually change the version number, and then I usually get a 
bug report within minutes of cutting the release with a snickering "hah, 
you forgot to change the version again".

So I do lots of commits with that Makefile being dirty, without ever 
actually committing the Makefile changes themselves. "git commit -a" as a 
default would be absolutely _horrible_ for me.

I occasionally have other things dirty too in my tree - just random 
hacking. But the Makefile is dirty about 50% of the time for me, so it's 
the common case.

And most of those commits are automated, either through pulls that are 
successful, or just my email patch-application scripts, and both of those 
cases actually check that the files that are _changed_ are never dirty in 
the working directory.

However, if the question was an even stricter "do you ever commit 
_changes_ to a particular file where the last HEAD, the index _and_ the 
working tree are all different", then the answer is actually "Yes" to that 
too.

What has happened is that I have had merges that have content conflicts 
that I fix up by hand, but exactly _because_ I fix them up by hand, I 
actually want to re-compile the kernel and test my fixups.

And in that case, I will actually re-apply my manual Makefile change, even 
if that file was part of the merge changes (in which case I had had to 
first un-apply the change in order to do the merge).

So what happens is that I recompile with my trivial changes in place 
_after_ I have fixed up any merge conflicts, reboot the thing to test, and 
then commit the result if everything looks ok.

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.

So I commit file contents that differ from my current working tree all the 
time.

ALMOST all of the time, the actual _changes_ that I commit do not actually 
touch the files that I have dirty, but as explained above, even that is 
not at all impossible.

The thing is, once you get used to the git "index" as a staging place, 
it's really really powerful. 

> Idea #2 (make it easy to preview diffs of what will be committed)
> -------
> Independent of the above, I'd like to propose another change to help
> prevent confusion and to help users learn git. There should be an
> obvious "diff" operation that presents exactly the result of what any
> "commit" operation will perform.

Actually, we do exactly that. Right now we expressly limit the "preview" 
to just the filenames, but we literally do run

	git-diff-index -M --cached --name-status --diff-filter=MDTCRA HEAD

as part of "git status", and the eventual end result is what we will 
populate the commit message file with for your editing pleasure.

And you can actually see that. 

So I would suggest that new git users never be told about the "-m" flag to 
"git commit", so that they always have to edit the commit message by hand, 
because that commit message will contain exactly this information.

Not the patch itself, though. Maybe we could make it show part of it, 
though, if somebody really wants to see it ;)

		Linus