Re: Creating remote branch called HEAD corrupts remote clones

[Erik Faye-Lund <kusmabite@gmail.com>]

On Mon, May 2, 2011 at 9:26 PM, Stephen Kelly <steveire@gmail.com> wrote:
> 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.
>

No, it's still an issue, and I believe I pin-pointed it in my first
mail. You can try out the patch I sent, and see if that helps in your
case. If it does, I think it'd make sense to do something (preferably
a bit more robust) with it.