Re: [topgit] tg update error

[Junio C Hamano <gitster@pobox.com>]

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

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

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

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