Carl Worth <cworth@xxxxxxxxxx> writes:
> On Thu, 21 Dec 2006 20:13:52 -0800 (PST), Linus Torvalds wrote:
>> I do it all the time, I never even use the old-fashioned syntax any more.
>> It's much more concise and easy to read, and it has all the nice shortcuts
>> (like empty meaning "HEAD", so you can do "git diff ..next" to see the
>> diff from HEAD to another branch).
>
> I can understand the advantage of a shortcut like "git diff ..next",
> but I still don't understand why it's the comparison of HEAD and next
> that's really interesting here. Wouldn't comparing the merge-base to
> next be more desirable?
"git diff ...next" should work just as well, I think.
> But, really, I still don't understand exactly _what_ "diff a..b" even
> means. Can you explain it to me?
diff between two points.
> Presumably the rev-parse magic is happening to the arguments. So does
> the diff code just end up seeing the expanded equivalent of "b ^a" and
> then just use the ^ to decide which tree to be on the left side or
> something?
Exactly; diff just reuses the non-magic part of revision
parameter parsing without using the ancestry traversal
machinery (which is the magic part).
>> It's also useful exactly because of the semantics of things like "...".
>
> And now I'm really confused. If I'm not mistaken, rev-parse will turn
> "a...b" into something like "a b ^$(merge-base a b)", right? So does
> the diff code now end up seeing three different tree specifiers? What
> does it do with that?
It knows that rev-parse makes it "b a ^base", and it knows what
the user meant is "base..b".
That's all because we teach them to spell "a...b" when they want
"base..b". Similarly, because we allow them to spell "a..b"
when they mean "between two points, a and b", it handles "b ^a"
as the equivalent to giving two trees separately, as "a b".
> And how is this useful? (As you said before,
> diff is always going to end up acting on only two items, so I don't
> see where there could be an interesting distinction from how you
> obtain two items from "a..b" compared to "a...b".) But it might be
> just that I'm really confused here.
I do not think you are seriously saying that comparing A and
B in this picture is meaningless:
o---o---B
/
---M---o---A
Yes, it is often useful to compare M and B, but that "often" is
limited to the phase of the workflow where you are at A and are
contemplating of merging B. But merging two forked branches is
not the only thing you do.
Comparing two revisions regardless of how they are topologically
related is useful as often. It is only that it may not as
useful while you are trying to merge B into A.
So there are two ways to let you do both, and they need to be
specified differently (.. vs ...) because you need to tell it
to do which one.
-
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