Re: [topgit] tg update error

martin f krafft [off-list ref] 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?

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?