perryh@xxxxxxxxxxxxxx (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 ;-).
> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html