Re: Command-line interface thoughts

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

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 <gitster@pobox.com> wrote:
> Jeff King <peff@peff.net> writes:
>
>> 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.
>
>>   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.
>