Re: Creating remote branch called HEAD corrupts remote clones

From: Erik Faye-Lund <kusmabite@gmail.com>
Date: Apr 27, 2011, 12:49 UTC
Message-ID: <BANLkTikxS-_9h4rBdbbJ2e-RkjMWyiC1Mg@mail.gmail.com>
In-Reply-To: <BANLkTimLnggco_+mQZ2_T_myAHsDD-=g1w@mail.gmail.com>

On Wed, Apr 27, 2011 at 2:21 PM, Erik Faye-Lund <kusmabite@gmail.com> wrote:

Show 42 quoted lines

> On Wed, Apr 27, 2011 at 1:29 PM, Stephen Kelly <steveire@gmail.com> wrote:
>> On Wed, Apr 27, 2011 at 11:48 AM, Felipe Contreras
>> <felipe.contreras@gmail.com> wrote:
>>> No problems here:
>>
>> I had another go.
>>
>> mkdir remote
>> cd remote/
>> git init --bare
>> cd ../
>> git clone remote/ alice
>> cd alice/
>> echo test >> file
>> git add file
>> git commit -am w
>> git push origin master
>> echo test >> file
>> git commit -am w
>> git branch HEAD
>
> I'll stop you here. You reproduce the issue a lot simpler:
>
> git init foo &&
> cd foo &&
> echo "foo" > bar &&
> git add bar &&
> git commit -m. &&
> git branch HEAD &&
> gitk
>
> No need to involve remote branches. While remote branches makes the
> issue worse, because you can get in a situation where gitk doesn't
> when someone else made a nasty branch, and you fetched it.
>
> The real problem is that "git rev-parse HEAD" outputs "warning:
> refname 'HEAD' is ambiguous." to stderr (even if stderr is a non-tty),
> and gitk does not like that.
>
> This can be fixed by either doing "git -c core.warnambiguousrefs=0
> rev-parse HEAD", which strikes me as ugly, or by making sure that we
> don't issue this warning when not attached to a tty:

Of course, a third (and probably even better) option is to make gitk warn about the ambiguous refname (like other commands will), but not treat it as a fatal problem. But I'm not motivated enough to give that solution a stab myself.

Not outputting that warning might be a regression for other users of rev-parse (and/or the underlying mechanics).