Re: [topgit] tg update error

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 12, 2009, 23:14 UTC
Message-ID: <7vocx7i6xh.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <20090212214106.GC26573@piper.oerlikon.madduck.net>

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

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

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?

Show 5 quoted lines

> Point being: I understand the reason behind the restriction, and
> I wouldn't mind if it were default, but maybe there could be
> a controlled way to circumvent it for cases like the one described
> above, where it is safe to assume that the user^W^W the tool "knows"
> what it is doing.

Sure, the tool would know what it is doing, I wouldn't doubt that.

But the end users don't. If TopGit dies (or killed) during the base flipping operation, doesn't the end user left in a funny state (granted, a detached HEAD is also a funny state, but it is already a known funny state they are familiar with. HEAD that is a symref but points outside refs/heads/ is a lot funnier).

You did not actually answer a larger question. What other undocumented features/restrictions does the code depend on, that tightening them to help normal git users inadvertently may cause breakages similar to this one in TopGit?