Re: Updated Kernel Hacker's guide to git

[Jakub Narebski <jnareb@gmail.com>]

[Cc: Carl Worth <cworth@cworth.org>, Linus Torvalds <torvalds@osdl.org>
 git@vger.kernel.org]

Carl Worth wrote:

> 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? For example, if I'm considering whether to
> merge in next or not, why should I care to see in the diff all the
> irrelevant stuff that's happened on HEAD since next branched off?
> 
> But, really, I still don't understand exactly _what_ "diff a..b" even
> means. Can you explain it to me?

For me, it's just a bit of syntactic sugar (I always have in mind that
git-log and friends outputs commit list and use revisions range, while
git-diff and friends needs two (or less) revisions) allowing to
copy'n'paste arguments from "git log a..b" to "git diff a..b"
 
> 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?

And that is just implementation. I don't think anyone uses "git diff b ^a".

>> 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? 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 would have thought that it would be combined diff of a and b against
it's merge base... but it is not.

"git diff a...b" is turned into "git diff a b ^$(git merge-base a b)",
and by a bit of magic (and by a convention) it is turned into
"git diff ^$(merge-base a b) a" (and a...b ceases to be _symmetric_
for git-diff).

I'd like for "git diff --cc a...b" to do 'the right thing' and show
git diff --cc for pretended merge (I'm not sure if with or without
resolving trivial conflicts).

>> So "git diff a b" doesn't even look good to me any more, because it's
>> literally missing that mental "to" that the ".." adds for me when I read
>> it.
> 
> OK, that's fine. But can you comment on why you want the comparison
> between the tips and not something based on a comparison from the
> merge-base to a tip?

a..b does not imply merge-base, a...b does.

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git