Re: Creating remote branch called HEAD corrupts remote clones

[Stephen Kelly <steveire@gmail.com>]

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

Ok, if you can't see in the code why a branch called HEAD might
corrupt the remote and I can't demonstrate it with a testcase, maybe
it's not an issue anymore, I don't know.

Hopefully the relevant people saw the side issues brought up such as
this ambiguous ref issue. After all, there's no other way to track
those issues.

Thanks for the investigation and help,

Steve.