Re: Creating remote branch called HEAD corrupts remote clones

> On Wed, Apr 27, 2011 at 2:21 PM, Erik Faye-Lund <kusmabite@gmail.com> wrote:
>> 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).
>