Inconsistency in specifying commit & path for git diff

Inconsistency in specifying commit & path for git diff

[Arthur Etchells]

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.

Re: Inconsistency in specifying commit & path for git diff

[Andreas Schwab]

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."

Re: Inconsistency in specifying commit & path for git diff

[Junio C Hamano]

Arthur Etchells <adetchells@gmail.com> 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