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

Duy Nguyen [off-list ref] writes:

On Thu, May 16, 2013 at 6:42 AM, Junio C Hamano [off-list ref] wrote:

quoted

* 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.

On Mon, May 20, 2013 at 11:17 PM, Junio C Hamano [off-list ref] wrote:

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.

Point taken. I guess the message would be something like this?

Refname '%.*s' is ignored. It may be created by mistake.

Or should we be more elaborate?
--
Duy