Re: Two ideas for improving git's user interface

On Fri, 3 Feb 2006, Carl Worth wrote:

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.

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.

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