Re: Creating remote branch called HEAD corrupts remote clones
- From
Erik Faye-Lund <kusmabite@gmail.com>
- Date
- May 2, 2011, 19:43 UTC
- Message-ID
- <BANLkTinJvt=Nnt8YG-D1wpWKbBei+m+4XA@mail.gmail.com>
- In-Reply-To
- <BANLkTinqxy6jCJLNVPKmMW3CErbfN7Hm=g@mail.gmail.com>
On Mon, May 2, 2011 at 9:26 PM, Stephen Kelly <steveire@gmail.com> wrote:
Show 58 quoted lines
> 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.