Re: Creating remote branch called HEAD corrupts remote clones

[Felipe Contreras <felipe.contreras@gmail.com>]

On Mon, May 2, 2011 at 10:43 PM, Erik Faye-Lund <kusmabite@gmail.com> wrote:
> 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.

Yes, I think your patch should be applied regardless, as that solves
_one_ issue.

But there are other issues.

-- 
Felipe Contreras