Duy Nguyen <pclo...@gmail.com> writes:

> On Thu, May 16, 2013 at 6:42 AM, Junio C Hamano <gits...@pobox.com> wrote:
>> * nd/warn-ambiguous-object-name (2013-05-07) 1 commit
>>  - get_sha1: improve ambiguity warning regarding SHA-1 and ref names
>>  "git cmd <name>", when <name> happens to be a 40-hex string,
>>  directly uses the 40-hex string as an object name, even if a ref
>>  "refs/<some hierarchy>/<name>" exists.  This disambiguation order
>>  is unlikely to change, but we should warn about the ambiguity just
>>  like we warn when more than one refs/ hierachies share the same
>>  name.
>>  The message needs to be fixed up, as this is not "refname is
>>  ambiguous".
> hm.. how should the message be rephrased? ambiguity of 40-hex string
> and a ref path?

At that point, the user gave us a full object name and we are going
to treat it as a full object name, no?  Wouldn't it be necessary to
let the user know that it is different from having two ambiguous refs?

Think why the user has such a hard to type ref in the first place.
The user may have done this previously, thinking that he is detaching
the HEAD to fix an earlier mistake in a branch:

    $ BAD_COMMIT=$(git rev-parse nd/magic~8)
    $ git checkout $BAD_COMMIT

but by mistake gave a "-b" after "checkout", i.e.

    $ git checkout -b $BAD_COMMIT

After this, commands that want to work on branch name would still
work as "expected", with the expectation being the user would be
working on the refs/heads/$BAD_COMMIT branch, e.g.

    $ git checkout $BAD_COMMIT
    $ git branch -m $BAD_COMMIT nd/magic-fix

but commands that want to work on commit object name will resolve it
to the $BAD_COMMIT object (i.e. nd/magic~8), e.g.

    $ git log $BAD_COMMIT

and needs disambiguation if the user wants to work on the commit at
the tip of the branch, e.g.

    $ git log heads/$BAD_COMMIT

So we really do want the users to notice and take corrective action,
and one way to attract the attention of the users is to phrase the
message more explicitly to let them know what is going on.

In addition to your topic, it may be a good idea to notice this at
the Porcelain level (e.g. "checkout -b" and "branch", but not at the
"update-ref" level) and warn or even die if a Porcelain tries to
create a branch with such a name.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to