[prev in list] [next in list] [prev in thread] [next in thread] 

List:       git
Subject:    Re: [topgit] tg update error
From:       Jeff King <peff () peff ! net>
Date:       2009-02-12 12:56:21
Message-ID: 20090212125621.GB5397 () sigill ! intra ! peff ! net
[Download RAW message or body]

On Thu, Feb 12, 2009 at 02:55:58PM +0530, Aneesh Kumar K.V wrote:

> On Thu, Feb 12, 2009 at 09:48:11AM +0100, martin f krafft wrote:
> > also sprach Aneesh Kumar <aneesh.kumar@gmail.com> [2009.02.12.0909 +0100]:
> > > doing a tg update with latest git gives the below error
> > >
> > > [extent_validate@linux-2.6]$ tg update
> > > fatal: Refusing to point HEAD outside of refs/heads/
> > > [extent_validate@linux-2.6]$
> >
> > Which version? And could you please provide (a lot) more information
> > about your repository or make it available?
> >
>
> Latest git and topgit. Moving to git version v1.6.1.3 fixed the issue.
> I can reproduce the problem on any test repo. Just do a tg update after
> committing something in the dependent branch.

This error message and safety valve are not in any released version of
git yet. So by moving back to 1.6.1.3, you are just predating the
addition of that message. :)

I think I know what is going on. A safety valve was added in afe5d3d to
disallow setting HEAD to anything that would violate git's "is this a
git directory" detector:

    symbolic ref: refuse non-ref targets in HEAD

    When calling "git symbolic-ref" it is easy to forget that
    the target must be a fully qualified ref. E.g., you might
    accidentally do:

      $ git symbolic-ref HEAD master

    Unfortunately, this is very difficult to recover from,
    because the bogus contents of HEAD make git believe we are
    no longer in a git repository (as is_git_dir explicitly
    checks for "^refs/heads/" in the HEAD target). So
    immediately trying to fix the situation doesn't work:

      $ git symbolic-ref HEAD refs/heads/master
      fatal: Not a git repository

    and one is left editing the .git/HEAD file manually.

Released versions of git just check "refs/" in HEAD. _But_ as part of
this patch series, b229d18 also tightened the "refs/" check to
"refs/heads/".

So what I suspect is happening is that topgit is trying to set HEAD to
"refs/top-bases/whatever". Aneesh, can you confirm by running your test
with GIT_TRACE=1?  I suspect you will see a call like "git symbolic-ref
HEAD refs/top-bases/foo".

Junio, I think we should probably revert b229d18 (and loosen
symbolic-ref's check to just "refs/"). Even if you want to argue that
topgit should be changed to handle this differently, we are still
breaking existing topgit installations, and who knows what other scripts
which might have relied on doing something like this.

-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
[prev in list] [next in list] [prev in thread] [next in thread]