Re: Command-line interface thoughts

I'm going to accept Junio's reply at a sign to withdraw.

It is clear that implementing NEXT/WTREE will worsen the performance
of some commands ("git diff" under merge conflict).  I can accept that
the community does not want to give up performance to include an
incomplete idea that offers no quantifiable improvement.


I agree with Haggerty that the value of NEXT and WTREE to the user
will be seen when they are used in multiple commands.  That is, when
they are part of a collection of porcelain-level concepts that the
user can work with.

I'm going to start a discussion on those porcelain-level concepts.  I
don't think this mailing list is the right forum for it.  If you wish
to be a part of the discussion, please email me.

If the discussion produces something of value, I look forward to
returning and presenting it to the mailing list.

Mike


On Fri, Jun 10, 2011 at 5:48 PM, Junio C Hamano [off-list ref] wrote:

Jeff King [off-list ref] writes:

quoted

I think there are actually two questions here:

  1. Will it be easier for people to understand "git diff" if we use
     tokens to describe non-treeish sources and destinations?

  2. Are there better tokens to use to break down parts of the index?

I don't have a big problem with (1). Allowing things like:

  git diff INDEX WTREE

allows one to explain what is going on with the diff syntax in a very
clear and verbose manner. I wouldn't want to type that every day, but
that's OK; "git diff" will always mean the same thing as it always has,
but can now be explained to people who have trouble seeing it in terms
of "git diff INDEX WTREE".

There's still a bit of magic in that INDEX is _not_ a tree, but I think
that's a good thing. When there are no merge conflicts, it will behave
identically to the proposed NEXT tree. And when there are conflicts, it
will show you something even more useful.

Thanks. This is exactly why I love to have people like you on the list,
who can say what I wanted to say in a matter that is a lot easier to
understand.

In short, the proposed "NEXT" does not help in a situation with conflicts,
and makes the user experience worse. In order to get the current power of
"git diff" with various options that are specifically designed to help
users to make progress (either working on their own changes, rebasing them
on top of others, or merging other's work in), people _COULD_ introduce
BASE/OURS/THEIRS in addition to "NEXT", throw the existing HEAD and
MERGE_HEAD to the mix, derive the same information by spending mental
effort to choose between which pairs of two entities among these six
possibilities and take pairwise diffs among those pairs, and combine the
results of these diffs (the message I responded to with "is that a useful
question" was an example of that---"Could we pile more kludge on top of
NEXT to have expressiveness equivalent to what the current index-based
system offers?"). Yes, that may be possible, but is there a point in
making users go through that kind of mental contortion by introducing
these new tokens? I find it highly doubtful that it would help new people
understand the situation during conflicted merges.

quoted

  git show INDEX:OURS:Makefile

which is identical to what I wrote above, but is perhaps easier to
explain.

Why does anybody even want to say :2:Makefile to begin with?

Presumably, you are dealing with a merge conflict at that path and trying
to see how pre-merge version of Makefile looked like, and then the next
thing you may want to do is how pre-merge version of their Makefile looked
like.

Wouldn't it be far more natural to ask for these instead?

   git show HEAD:Makefile
   git show MERGE_HEAD:Makefile

I do not think whoever brought that "you can look at individual stages
with :$n:$path" to this discussion was thinking straight. Yes, it is
something you _could_ do, I've never found that particularly _useful_
unless I was debugging git itself.