Re: Command-line interface thoughts

[Michael Nahas <mike.nahas@gmail.com>]

I think NEXT and WTREE should be like tree objects, not commits, so I
would argue that "git show NEXT" should show what it shows for a tree.
 From the man page:

"For trees, it shows the names (equivalent to git ls-tree with --name-only)."


"git diff HEAD NEXT" during a merge conflict: During the merge
conflict there are two groups of changing files.  Some files have been
resolved and reside in "Stage0".  The others have not been resolved
and a copy resides in each of "Stage1", 2, and 3.  (Which I eagerly
want to name BASE, HEAD, and MERGE_HEAD.)

My thought is that NEXT should only represent those changing files
that have been resolved.  So, NEXT would be HEAD plus the files in
Stage0.  So, "git diff HEAD NEXT" would print out the changes in
Stage0.

The trickier question for me is what does this make "git diff WTREE
NEXT"?  Well, the resolved changes are the same in WTREE and NEXT.
The unresolved files in NEXT are the same as in HEAD.  So, "git diff
WTREE NEXT" would print out the unresolved changes between WTREE and
HEAD.

What I don't like about that is that at the point of conflict in each
file, "git merge" has written the changes from HEAD and MERGE_HEAD.
So, printing the changes between HEAD and WTREE will resulting in the
changes done by HEAD printed twice.  That, while understandable, isn't
so pretty.


I've engineered a conflicted merge and taken a look at what "git diff
--cached HEAD" and "git diff --cached" looks like.  Can someone
confirm that the current behavior is equivalent to what I described
above?


Junio asked: So what should it look like during a "pull" that did not finish?

Is this the same as a conflicted merge state?  (Except possibly with
FETCH_HEAD instead of MERGE_HEAD.)


Junio asked: "rebase -i"?

I know what this does (and love it!), but not how it works.  I
certainly don't know the state it leaves things in when it's
conflicted.  I'll let someone else go to bat here.


Teach a noob: What's "rc phase"?


Mike



On Mon, Jun 6, 2011 at 3:01 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
> 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.
>