Re: resolving a (possibly remote) branch HEAD to a hash

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 7, 2015, 17:24 UTC
Message-ID: <xmqq8u9nyptx.fsf@gitster.dls.corp.google.com>
In-Reply-To: <55c47766.dDi8LaxdDqOeptUd%perryh@pluto.rain.com>

perryh@pluto.rain.com (Perry Hutchison) writes:

>   $ git rev-parse r5.0.1
>   r5.0.1
>   fatal: ambiguous argument 'r5.0.1': unknown revision or path not in the working tree.
>   Use '--' to separate paths from revisions

This is not because of ambiguity among refs. The message is telling you:

    r5.0.1 is not interpretable as a revision, and it is not likely
    to be interpretable as a path.  If you meant to use it as a
    revision, put '--' after it, if you meant to use it as a path,
    put '--' before it.

When we try to see if the user meant "r5.0.1" as a revision or a path on a command line that does not have "--", we make sure that it can be interpreted only as a revision but not as a path or the other way around. You see the above error when it cannot be a revision and it does not appear in the _current_ working tree.

The "not likely to be" part comes because this is a heuristic to catch your typo. "git log r5.0.1" _could_ be a request to show a simplified history that ends with the current commit (i.e. HEAD) that touched the path r5.0.1 that used to exist but was removed in the history, and it is way too expensive to dig the history at that point to see if a path r5.0.1 ever existed, so we only check the current working tree.

Now, admittably, if you say "git rev-parse r5.0.1 --" in this situation, it is not likely that the corrected command line will succeed. After all, the error message was issued because we already know that r5.0.1 is _not_ a correct way to spell any revision. So the message _might_ want to be reworded to make it clear that:

 * 'r5.0.1' is not a valid revision name.  Perhaps you misspelt it?

 * 'r5.0.1' does not exist in the current working tree.  Perhaps you
   misspelt it?

 * With 'r5.0.1', you may be trying to refer to a path that (might)
   existed in the past.  If that is the case, please have "--"
   before it to explicitly tell us that you mean a path, not a
   revision.

> It works if I explicitly specify that I want the remote instance:
>
>   $ git rev-parse origin/r5.0.1
>   bb193a818fc984adbfd631951f3c89c16d5d3476

This is the correct behaviour and the expected usage. When talking about r5.0.1 that came from origin, origin/r5.0.1 is the shortest and still valid way to spell it.

> and the reference is, in fact, not ambiguous:
>
>   $ git for-each-ref --format "%(refname)" | grep '/r5\.0\.1$'
>   refs/remotes/origin/r5.0.1

Because it is not about ambiguity among refs, this observation is irrelevant ;-).

Show 5 quoted lines

> Interestingly, master -- the one that works -- _is_ ambiguous:
>
>   $ git for-each-ref --format "%(refname)" | grep '/master$'
>   refs/heads/master
>   refs/remotes/origin/master

The thing is, there is no ambiguity among

    refs/heads/master
    refs/remotes/origin/master
    refs/remotes/another/master

because we do not say "append 'refs/remotes/<anything>/' for various values of <anything> and see if such a ref exists" when resolving an abbreviated refname 'master'.

Ambiguity among refs exists if you had these

    refs/heads/master
    refs/tags/master
    refs/remotes/master/HEAD

But that is not what we are seeing in your case.