Inconsistency in specifying commit & path for git diff

Arthur Etchells· Oct 9, 2012, 19:43 UTC · lore

git diff <commit>..<commit> and git diff <commit> <commit> both succeed

however git diff <commit>:<path>..<commit>:<path> fails while git diff <commit>:<path> <commit>:<path> succeeds

OS X 10.7.5 git version 1.7.9.1

Reproduced by another user: http://stackoverflow.com/questions/12805004/git-cherry-pick-creates-blobs-not-commits#comment17319876_12805004

It seems logical to support the '..' syntax in both for consistency.

Andreas Schwab· Oct 9, 2012, 20:37 UTC · re: Arthur Etchells · lore

Re: Inconsistency in specifying commit & path for git diff

Arthur Etchells <adetchells@gmail.com> writes:

> git diff <commit>:<path>..<commit>:<path>

<commit>:<path> represents a tree or blob, but .. requires commits as its end points.

(You can dereference a commit to get a tree or blob, but not the other way round.)

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Junio C Hamano· Oct 9, 2012, 21:03 UTC · re: Arthur Etchells · lore

Re: Inconsistency in specifying commit & path for git diff

Arthur Etchells <adetchells@gmail.com> writes:

Show 11 quoted lines

> git diff <commit>..<commit>
> and
> git diff <commit> <commit>
> both succeed
> however
> git diff <commit>:<path>..<commit>:<path>
> fails while
> git diff <commit>:<path> <commit>:<path>
> succeeds
> ...
> It seems logical to support the '..' syntax in both for consistency.

"git diff A..B" is an illogical thing to say in the first place. It only happens to work by historical accident, and for that "it used to work like so from the beginning, do not break backward compatibility" reason, we have kept it working.

But you are better off unlearning it to keep your sanity when learning git as a new user.

The dot notation is about a range. A..B talks about the set of commits that are ancestors of B but not ancestors of A.

    $ git log A..B

makes perfect sense to show such a range.

But "diff" is about "comparing two endpoints". There is nothing "range" about such a comparison. When you compare the state at A and at B, you do not even look at anything in between. That is why the canonical way to say it is

    $ git diff A B

and not

    $ git diff A..B ;# WRONG. DO NOT DO THIS.

And <commit>:<path> is a way to name an entity at <path> in the tree recorded in the <commit>. Typically you name a blob, not a tree that represents a subdirectory, with this syntax.

Now, B1..B2, when B1 and B2 are blobs (or anything that is not commit-ish), does not make sense even as a range, and such a request is detected as an error at the syntactic level (i.e. without even starting to "compare").

    $ git diff HEAD:Makefile..HEAD~4:Makefile ;# WRONG. DO NOT DO THIS.

If you want to compare two blobs, you can do so with the canonical "compare two things" syntax.

    $ git diff HEAD:Makefile HEAD~4:Makefile