git-history(1) fixup broken with worktrees?
4 messages between Jul 17, 2026 and Aug 20, 2026, from Toon Claes, Phillip Wood, Patrick Steinhardt.
Plain Markdown or JSON for tools and agents.
Hi,
Imagine this repoducer:
$ git init
$ echo Hello > README
$ git add .
$ git commit -m'initial commit'
$ git worktree add ../feature
$ echo world >> README
$ git add .
$ git history fixup HEAD
$ cd ../featureNow running git-status(1) in that other worktree gives me:
$ git status
On branch feature
Changes to be committed:
(use "git restore --staged <file>..." to unstage)
modified: READMEAnd:
$ git diff --staged
diff --git a/README b/README
index 65a56c3..e965047 100644
--- a/README
+++ b/README
@@ -1,2 +1 @@
Hello
-worldSo suddenly my other worktree is dirty? With staged changes? And I didn't even touch it.
Now the commit history is correct:
$ git log --graph --oneline --all
* 16ef548 (HEAD -> feature, main) initial commit
--
Cheers,
Toon
Re: git-history(1) fixup broken with worktrees?
Hi Toon
On 17/07/2026 19:54, Toon Claes wrote:
Show 37 quoted lines
>
> Imagine this repoducer:
>
> $ git init
> $ echo Hello > README
> $ git add .
> $ git commit -m'initial commit'
> $ git worktree add ../feature
> $ echo world >> README
> $ git add .
> $ git history fixup HEAD
> $ cd ../feature
>
> Now running git-status(1) in that other worktree gives me:
>
> $ git status
>
> On branch feature
> Changes to be committed:
> (use "git restore --staged <file>..." to unstage)
> modified: README
>
> And:
>
> $ git diff --staged
>
> diff --git a/README b/README
> index 65a56c3..e965047 100644
> --- a/README
> +++ b/README
> @@ -1,2 +1 @@
> Hello
> -world
>
>
> So suddenly my other worktree is dirty? With staged changes?
> And I didn't even touch it.
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. Rebase's --update-refs option refuses to update branches that are checked out in other workers by default to avoid exactly this problem[1]. 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.
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.
Thanks
Phillip
[1] https://lore.kernel.org/git/9354d1d3-c1b7-3baf-215f-30659ad48b22@github.com/
Show 8 quoted lines
> Now the commit history is correct:
>
> $ git log --graph --oneline --all
>
> * 16ef548 (HEAD -> feature, main) initial commit
>
>
>
Re: git-history(1) fixup broken with worktrees?
Phillip Wood <phillip.wood123@gmail.com> 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/590382fb-731b-4e14-911e-ff68356d1082@web.de
--
Cheers,
Toon
Re: git-history(1) fixup broken with worktrees?
On Tue, Jul 28, 2026 at 03:44:18PM +0200, Toon Claes wrote:
Show 22 quoted lines
> Phillip Wood <phillip.wood123@gmail.com> 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