Re: Inconsistency in specifying commit & path for git diff

Arthur Etchells [off-list ref] writes:

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