Re: Command-line interface thoughts

From: Michael J Gruber <git@drmicha.warpmail.net>
Date: Jun 6, 2011, 07:34 UTC
Message-ID: <4DEC8322.6040200@drmicha.warpmail.net>
In-Reply-To: <7vwrgza3i2.fsf@alter.siamese.dyndns.org>

Junio C Hamano venit, vidit, dixit 06.06.2011 08:16:

Show 25 quoted lines

> Scott Chacon <schacon@gmail.com> writes:
> 
>> For example, implementation details aside, I think having something
>> like WTREE and NEXT available would help users understand that there
>> are these 3 trees that are important and useful in Git and re-inforce
>> a very non-SVN style workflow in that manner.
> 
> That's a funny thing to say. Working tree may almost always (to put it
> another way, "you could make it to") act like a tree, but the index does
> not act like a tree at all in more important situations.
> 
> For example, how would you design the user experience of "git show NEXT"?
> Try to write a transcript (i.e. "The user starts from this state, runs
> these commands, and then says 'git show NEXT'. The user will see this."),
> covering various corner cases exhaustively, including what would happen
> before the first commit, and during a conflicted "pull" or "rebase -i".
> 
> It's not just the matter of "internally pretend to run write-tree with
> 'not committed yet' as a fake commit log message and show it as if it is
> an existing commit.
> 
> I wouldn't demand "implement 'git show NEXT'" here, nor "implement it
> efficiently" here; just designing the user experience is a good first step
> to realize that the index does not act like a tree, and I do not think you
> should spread such a misconception to the end users.

That is why the other Michael suggested "NEXT" as opposed to "INDEX": The index has many aspects, only one of which is "the contents of the next commit if I would issue 'git commit' right now". (I would even go so far as using "STAGE".) Now, it's hard to argue that "the result of a commit" is not tree-like, isn't it? And there's no question what "git show NEXT" would do. Yes, if you repeat that command, you get a different sha1 each time (because of the time field).

I don't think anyone is seriously suggesting to replace the index by a pseudo commit; but the one aspect which people use most could be well represented like that, and this might even help emphasizing the different aspects of the index. Give the index an identity as an "object" (no, no new type, not in the object db, but as a ui object), not something mysterious behind the scenes!

As for WTREE: git diff against work tree does not look at non-tracked ignored files, so why should WTREE?

Full disclosure: I love the index but hate the way we make it difficult to use sometimes, and even have to lookup myself what command and option to actually use if all I want to do is diff A against B, or take the version of a file from A and write it to B, when A and B are a commit, the index or the worktree (with a commit being the nonwritable, of course).

I mean, this is really crazy: We have 4 commands ("add", "rm [--cached]", "checkout [<commit>] --", "reset [<commit>] --") which you need to be aware of if all you want to do is moving file contents (content at a path) between a commit, the index and the worktree! And this is actually worse than having 6 for the 6 cases.

Michael