Question

There was a regression in a feature added a few months back. The feature was introduced in three separate commits. In order to restore the functionality I wanted to git cherry-pick the three commits onto a branch (rel060) created from the last tag (release-0.6.0) made before the commits were merged in to production, indicated by git describe.

This completed, I want to compare the results of this operation to the contents of a file on current production head.

git co -b rel060 release-0.6.0
git cherry-pick ead47f2
  [rel060 f28fed4] Corrects non-display of subtabs. (SITE-657)
  1 files changed, 5 insertions(+), 8 deletions(-)
git cherry-pick b22c4d4
  [rel060 b0014f1] Correct subtab bug in Firefox/IE. (SITE-657)
  1 files changed, 18 insertions(+), 24 deletions(-)
git cherry-pick ae5a321
  [rel060 5b41410] Corrects bug with subtab line collapse. (SITE-657)
  1 files changed, 5 insertions(+), 1 deletions(-)
git diff rel060:./cron_lp_functions.php..production:./cron_db_lpgenerate.php
  error: Object 2ce3dd45e32e1bef6da0b22a9ee7208c63e203d2 is a blob, not a commit
  error: Object f41574b41b82aba51876b5f7aba0d3ff9c6677c5 is a blob, not a commit
  fatal: Invalid revision range rel060:./cron_lp_functions.php..production:./cron_db_lpgenerate.php

For what it’s worth, attempting to tab autocomplete at cron_lp_… produced: Not a valid object name rel060:.

The functions file is a file whose contents were later rolled in to the lpgenerate.

Now, I realize there are a million easier alternatives to do what I want to do (see the three commits as one diff, diff the tag releasing the feature to the current state of the lines in question).

What I want to know is this: why did I get the particular errors? As it turns out, cherry-picking seems to have nothing to o with the problem. Attempting the diff after creating the branch from the tag produces the same error. Have I missed something fundamental in git? Creating a branch from a release seems innocuous… are there some innocuous gotchas I’m not picking up on?

Answer 1

The reason for this is git diff <commit>..<commit> exists only to maintain backward compatibility and is syntactically ‘wrong’.

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 : is a way to name an entity at in the tree
recorded in the . 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

Answer from Junio C. Hamano, via [e-mail]