From: Brandon Casey <casey@nrlssc.navy.mil>
Date: Thu, 07 Jun 2007 14:54:46 GMT
Subject: Re: git does the wrong thing with ambiguous names
Message-ID: <46681C36.4060305@nrlssc.navy.mil>
In-Reply-To: <20070606233327.GD3969@steel.home>

Alex Riesen wrote:
> Alex Riesen, Thu, Jun 07, 2007 00:58:26 +0200:
>> Brandon Casey, Thu, Jun 07, 2007 00:13:48 +0200:
>>> When a branch and tag have the same name, a git-checkout using that name 
>>> succeeds (exits zero without complaining), switches to the _branch_, but 
>>> updates the working directory contents to that specified by the _tag_. 
>>> git-status show modified files.
>> Bad. To reproduce:
>>
>> mkdir a && cd a && git init && :> a && git add . && git commit -m1 &&
>> :>b && git add . && git commit -m2 && git tag master HEAD^ &&
>> find .git/refs/ && gco -b new && gco master && git status
>>
> 
> git-rev-parse actually warns about ambguities:
> 
>     $ git-rev-parse --verify master
>     warning: refname 'master' is ambiguous.
>     dd5cdc387f2160bf04d02ac08dfdaf952f769357
> 
> It's just that the warning is thrown away in git-checkout.sh
> 
> A quick and _very_ messy fix could like like that:

[snip patch]

This one suffers from what Junio described previously on the mailing 
list, when get_sha1_basic() fails, get_sha1_1() continues trying 
alternatives. The risk is that one of those alternatives could match, 
for example if the ambiguous branch and tag name is 'dead'.

-brandon