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). -- 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