Jeff King <peff@xxxxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html