On Fri, Apr 08, 2022 at 12:45:14AM +0200, Christian Weisgerber wrote:
> Stefan Sperling:
> 
> > The ref which is missing is only created if we manage to attempt a file
> > merge during the rebase operation. However, the path-prefix check currently
> > runs between the rebase_prepare() step and the merge_files() step.
> > So if the path-prefix check errors out we end up not creating a 'commit-'
> > reference, which is a problem I overlooked.
> 
> Oh, so rebasing the same branch in another work tree has nothing
> to do with it.

Right. It is just the first work tree that got confused.

> > Deleting all other rebase-related references should recover your work tree:
> > 
> > got ref -d refs/got/worktree/rebase/branch-e001ae79-bf70-4253-bac2-bdced68c8189
> > got ref -d refs/got/worktree/rebase/newbase-e001ae79-bf70-4253-bac2-bdced68c8189
> > got ref -d refs/got/worktree/rebase/tmp-e001ae79-bf70-4253-bac2-bdced68c8189
> 
> It doesn't.  I'm stuck on a magic branch I can't get off:

Ah, yes, the work tree needs to be switched, too.

> refs/got/worktree/base-e001ae79-bf70-4253-bac2-bdced68c8189: aeeb6b7d976582bc8997928f45a911d2cb880ff5
> refs/heads/master: aeeb6b7d976582bc8997928f45a911d2cb880ff5
> refs/remotes/origin/master: aeeb6b7d976582bc8997928f45a911d2cb880ff5

Your work tree is still based on the above commit, so this should work:

$ echo refs/heads/master > .got/head-ref 

And just in case:

$ got update