Re: [topgit] tg update error

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 13, 2009, 07:32 UTC
Message-ID: <7vmycqeqqh.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <20090213062818.GB16434@piper.oerlikon.madduck.net>

martin f krafft <madduck@debian.org> writes:

Show 10 quoted lines

> also sprach Junio C Hamano <gitster@pobox.com> [2009.02.13.0014 +0100]:
>> > TopGit would need to make a proper branch, merge the bases into
>> > it, merge that branch into the topic branch, and the probably
>> > delete the branch pointer, as it's no longer needed and would
>> > only pollute the refs/heads/* namespace.
>> 
>> So it happens purely inside TopGit and the end user never sees
>> a state that HEAD points outside refs/heads/, right?
>
> Yes.

Now I am confused by your answers. This "Yes" means that setting HEAD outside refs/heads/ happens purely as an intermediate state to avoid setting HEAD to some branch ref. After the operation finishes correctly, HEAD will never be left outside refs/heads/. But this contradicts directly with what you say next.

Show 6 quoted lines

>> Why can't the base flipping operation you descibed be done on
>> detached HEAD?  Perhaps with a shell variable or two that hold
>> commit object names you need to keep track of while it is doing is
>> work?
>
> I am not sure I understand. Isn't that what's currently happening?

If you *are* setting HEAD to some ref that is outside refs/heads (or even inside refs/heads for that matter), at that point the HEAD is *not* detached, so no, it obviously is *not* what is happening.

I am asking why you need to use a ref to do that, *if* it is a tentative state while the program is running. You are probably calling a git plumbing or Porcelain command that updates HEAD, and the reason why you point HEAD outside refs/heads/ is beause you would want the command you call to update one of the refs/top-bases/ ref through HEAD. I am asking why you are not running these commands on a normal detached HEAD, and then use update-ref (not symbolic-ref) plumbing to update the refs/top-bases/ ref you would want to update when it is done.

>> You did not actually answer a larger question.
>
> It wasn't asked to me before... ;)

Go back to the original message and read it again.

Show 5 quoted lines

> Up until now, however,
>
>   git checkout -q "refs/top-bases/$name"
>
> was not really something undocmented or restricted.

Giving checkout anything that is not "a branch name" meant detaching HEAD ever since detached HEAD was introduced, and that is a documented feature. git checkout "refs/heads/master" would behave the same way --- it won't check out the 'master' branch.

> I can still call e.g. git update-ref (as opposed to e.g. git
> _update-ref)  and potentially turn my repository upside down
> exemplifies this.

The distinction between Porcelain and plumbing is unfortunately not very clear at places. The change we reverted was probably a bad one. The stricter check was not done at the Porcelain level but was done at the plumbing level.