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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, May 20, 2013 at 11:17 PM, Junio C Hamano <gitster@xxxxxxxxx> 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
--
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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]