Re: Two ideas for improving git's user interface

[Linus Torvalds <torvalds@osdl.org>]

On Fri, 3 Feb 2006, Carl Worth wrote:
> 
> > 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).
> 
> Are the un-apply and re-apply operations here primarily manual? or
> does git help you much with those (beyond alerting you that the merge
> cannot take place before you un-apply things)?

They're purely manual. If the changes are more extensive, I just create a 
temporary branch for them, which is easy enough:

	git checkout -b temp
	git commit
	git checkout master

before I do the real merge, but the fact is, most of the changes in my 
tree tend to be pretty un-interesting. Most of the time it's literally 
_just_ the Makefile change, sometimes it's a trial patch that I'm not 
ready commit and had just sent out to somebody for testing or similar.

> I believe that the staging operations you perform are quite desirable,
> but I wonder if existing primitives in git might not provide a more
> powerful basis for the kinds of operation you're performing.

No. The point is that they are trivial to do, and that they don't _need_ 
"powerful basis".

What they need is _usability_.

And the git index _is_ that usability. It is incredibly powerful, and 
incredibly easy to use.

When you argue against exposing the index, you argue against it from the 
"let's not give them rope" angle. You argue against power and flexibility. 

You argue for the clippy, the helper app that says

	Are you sure you want to do this?
		[Yes] [No] [Cancel]

while I'm trying to explain that it's actually part of the _power_ of git.

The fact, that I can keep dirty state in my tree and continue to work with 
it _without_ having to worry about it is a huge relief to me. 

> If so, could your not-ready changes be implemented as some branch that
> is automatically unmerged prior to commit and then re-merged
> afterwards? Or something like that?

Sure. They could. You could make things more complicated, and they would 
WORK. 

They'd be inconvenient and not offer any actual improvement.

The "index" file in git really is very important.

Staging into the index is _the_ most fundamental operation. You can't 
actually see it very well in the history of git (because the first commit 
exists only after git actually worked pretty fully), but the birth of git 
is really in the index file. That actually came _before_ the object store, 
as the way to quickly and efficiently track the notion of "changes".

So git itself started out very much with the index file being the staging 
area for tracking the state of a working tree efficiently.

No git operation actually ever lets the working tree interact directly 
with the object store. The notion of "diff this <tree> object against the 
current working tree" comes closest, but even that actually really goes 
through the index file: it's properly a "diff this <tree> object against 
the index file, and check at the same time the index entry against the 
working tree"

If you deny the index file, you really deny git itself.

Think of it this way: when you start a new process, in UNIX you do that in 
two stages: first you fork() to create a copy, then you do exec() to 
populate the copy with the new process. 

Your argument is akin to saying "That's horribly wasteful: wouldn't it be 
much more intuitive to just do 'spawn()' to do it all, and avoid the 
unnecessary middle step".

But that "unnecessary" middle step - whether it's "fork()" or the git 
"index" file - is actually the source of the flexibility. It's what allows 
you to do the "fixups" in the middle when you switch file descriptors 
around, or when you fix up merge conflicts.

And then occasionally, you do fork() _without_ doing an execve() at all. 
The same way that sometimes you do operations on the index without 
actually committing them to a tree.

That's flexibility. Revel in it, instead of trying to push it under the 
rug. 

			Linus