Re: Two ideas for improving git's user interface

On Wed, 1 Feb 2006, Carl Worth wrote:

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.

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