Re: Command-line interface thoughts

[Junio C Hamano <gitster@pobox.com>]

Scott Chacon <schacon@gmail.com> writes:

> On Mon, Jun 6, 2011 at 9:14 AM, Junio C Hamano <gitster@pobox.com> wrote:
> ...
>>>> That is why I asked what the user experience of "git show NEXT" as opposed
>>>> to "git show INDEX" should look like. So what should it look like during a
>>>> "pull" that did not finish?
>>>
>>> If NEXT is to mean the result of a commit in the current state, and the
>>> current state would or should not allow a commit, then trying to access
>>> that pseudo-commit should error out with a helpful message.
>>
>> What "helpful message"? I asked for the user experience, not handwaving.
>>
>> Do you mean to say that the error message would teach the user that the
>> current state is not something you can create a commit? What message would
>> that give the end user?  I am hoping the following is not what will happen:
>>
>>  Q. I tried "git show NEXT" because I wanted to see what the next commit
>>     would look like, but I got an error, saying NEXT is not known as I
>>     haven't resolved a conflict.
>>
>>  A. Yes, the message is correct.
>
> I'm not sure why this wouldn't just list out the index tree,...

You are not entitled to say "I'm not sure" ;-). I asked you to show a
design of the user experience of "git show NEXT", as an advocate for the
NEXT/WTREE notation.

I'd take it that you would "just list out the index tree" as the outline
of the user experience.

>>  A. You would say "git diff HEAD NEXT".
>>
>>  Q. Ah, that is the same as I always do before making a commit to see what
>>     I have added so far look sane. Thanks.
>
> Why would this look sane? I would think this would say "* Unmerged
> path <file>" just like 'diff --cached would do.

Either you read it too hastily or I didn't write this clear enough; "sane"
does not refer to the command. In this story, the novice is saying "Before
I make a commit, I check if my changes so far matches what I wanted to
achieve, in other words, I check the sanity of my changes. And 'git diff
HEAD NEXT' is the command I use when I am not in this weird 'conflicted'
state. I am happy that I can use the same command".

> But, yes, I assume there would be some difficulty in supporting it
> everywhere.

I don't care too much about "difficulty in uniformly implementing". I am
doubting that you can _design_ uniformly for these new tokens to make
enough sense to help the new people. That is why I've been asking for
concrete examples of user experience design, sample transcripts, that
covers known corner cases.

If NEXT/WTREE advocates cannot come up with one, or if that is just to
punt and say "NEXT is not defined in this case---use the traditional
command" in the error message, I don't see much point in discussing this
further. It will end up with the same whine-fest as previous rounds.