Re: git-history(1) fixup broken with worktrees?

Phillip Wood <[email protected]> writes:

> I think what's happening is that the branch "feature" is updated because 
> the commit it points to is rewritten, but the index and working copy in 
> the work tree "feature" are not.

Yeah, it's relatively easy to understand what goes wrong, the fix would
be a bit more involved.

> Rebase's --update-refs option refuses to update branches that are
> checked out in other workers by default to avoid exactly this
> problem[1].

Ah, thanks for finding this existing discussion, interesting.

> As you can see in that thread there was some discussion about updating
> the index and working copy when the work tree is clean instead. I
> think that is a friendlier approach as it preserves the relationships
> between branches and avoids materializing changes in other worktrees.

Yeah, I agree it would be nice if git-history(1) would give it their
"best-effort".

> On a related note, rebase refuses to rewrite a branch that is being 
> rewritten by another rebase running in a different work tree. That's an 
> important safety measure that I think the history command is missing.

From [2] I've learned there are multiple ways a branch can be checked
out. We have to take them all into account. It can be build on top of
the changes in that patch.

[2]: https://lore.kernel.org/git/[email protected]

-- 
Cheers,
Toon