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? 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? > 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. > 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? -Carl
Attachment:
pgpJMUvmLjyVa.pgp
Description: PGP signature