[Cc: Carl Worth <cworth@xxxxxxxxxx>, Linus Torvalds <torvalds@xxxxxxxx> git@xxxxxxxxxxxxxxx] 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 - 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