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

On Tue, Jul 28, 2026 at 03:44:18PM +0200, Toon Claes wrote:
> 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".

Sorry, I missed this thread for quite a while. In any case, I agree that
we should probably do the same for git-history(1) as well and refuse
updating any branches that are currently checked out in another
worktree.

I've created an issue [1] for this scheduled for the next release cycle.
Happy if anybody else beats us to it though. Thanks!

Patrick

[1]: https://gitlab.com/gitlab-org/git/-/work_items/772