On Wed, Apr 27, 2011 at 2:49 PM, Erik Faye-Lund <kusmabite@xxxxxxxxx> wrote: > On Wed, Apr 27, 2011 at 2:21 PM, Erik Faye-Lund <kusmabite@xxxxxxxxx> wrote: >> On Wed, Apr 27, 2011 at 1:29 PM, Stephen Kelly <steveire@xxxxxxxxx> wrote: >>> On Wed, Apr 27, 2011 at 11:48 AM, Felipe Contreras >>> <felipe.contreras@xxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html