Re: What's cooking in git.git (May 2013, #04; Wed, 15)

From: Junio C Hamano <gitster@pobox.com>
Date: May 20, 2013, 16:17 UTC
Message-ID: <7vk3mtwrq9.fsf@alter.siamese.dyndns.org>
In-Reply-To: <CACsJy8Cr7AKxo9sUjMCVQ0=O91L8CRoxD3qrvZczCrBUq4TDzA@mail.gmail.com>

Duy Nguyen <pclouds@gmail.com> writes:

Show 16 quoted lines

> On Thu, May 16, 2013 at 6:42 AM, Junio C Hamano <gitster@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.