{"thread":{"id":"66031","subject":"git-history(1) fixup broken with worktrees?","startedAt":"2026-07-17T18:55:18Z","lastAt":"2026-08-20T13:20:53Z","messageCount":4,"participants":["Toon Claes","Phillip Wood","Patrick Steinhardt"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"548556","messageId":"87jyqt1m6g.fsf@emacs.iotcl.com","threadId":"66031","inReplyTo":null,"subject":"git-history(1) fixup broken with worktrees?","fromName":"Toon Claes","fromEmail":"toon@iotcl.com","sentAt":"2026-07-17T18:54:47Z","receivedAt":"2026-07-17T18:55:18Z","isPatch":false,"body":"Hi,\n\nImagine this repoducer:\n\n    $ git init\n    $ echo Hello > README\n    $ git add .\n    $ git commit -m'initial commit'\n    $ git worktree add ../feature\n    $ echo world >> README\n    $ git add .\n    $ git history fixup HEAD\n    $ cd ../feature\n\nNow running git-status(1) in that other worktree gives me:\n\n    $ git status\n\n    On branch feature\n    Changes to be committed:\n      (use \"git restore --staged <file>...\" to unstage)\n            modified:   README\n\nAnd:\n\n    $ git diff --staged\n\n    diff --git a/README b/README\n    index 65a56c3..e965047 100644\n    --- a/README\n    +++ b/README\n    @@ -1,2 +1 @@\n     Hello\n    -world\n\n\nSo suddenly my other worktree is dirty? With staged changes?\nAnd I didn't even touch it.\n\nNow the commit history is correct:\n\n    $ git log --graph --oneline --all\n\n    * 16ef548 (HEAD -> feature, main) initial commit\n\n\n\n-- \nCheers,\nToon\n"},{"id":"548583","messageId":"e7dbcede-4486-459c-aa64-e44690e01fe0@gmail.com","threadId":"66031","inReplyTo":"87jyqt1m6g.fsf@emacs.iotcl.com","subject":"Re: git-history(1) fixup broken with worktrees?","fromName":"Phillip Wood","fromEmail":"phillip.wood123@gmail.com","sentAt":"2026-07-18T09:31:18Z","receivedAt":"2026-07-18T09:31:21Z","isPatch":false,"body":"Hi Toon\n\nOn 17/07/2026 19:54, Toon Claes wrote:\n> \n> Imagine this repoducer:\n> \n>      $ git init\n>      $ echo Hello > README\n>      $ git add .\n>      $ git commit -m'initial commit'\n>      $ git worktree add ../feature\n>      $ echo world >> README\n>      $ git add .\n>      $ git history fixup HEAD\n>      $ cd ../feature\n> \n> Now running git-status(1) in that other worktree gives me:\n> \n>      $ git status\n> \n>      On branch feature\n>      Changes to be committed:\n>        (use \"git restore --staged <file>...\" to unstage)\n>              modified:   README\n> \n> And:\n> \n>      $ git diff --staged\n> \n>      diff --git a/README b/README\n>      index 65a56c3..e965047 100644\n>      --- a/README\n>      +++ b/README\n>      @@ -1,2 +1 @@\n>       Hello\n>      -world\n> \n> \n> So suddenly my other worktree is dirty? With staged changes?\n> And I didn't even touch it.\nI think what's happening is that the branch \"feature\" is updated because \nthe commit it points to is rewritten, but the index and working copy in \nthe work tree \"feature\" are not. Rebase's --update-refs option refuses \nto update branches that are checked out in other workers by default to \navoid exactly this problem[1]. As you can see in that thread there was \nsome discussion about updating the index and working copy when the work \ntree is clean instead. I think that is a friendlier approach as it \npreserves the relationships between branches and avoids materializing \nchanges in other worktrees.\n\nOn a related note, rebase refuses to rewrite a branch that is being \nrewritten by another rebase running in a different work tree. That's an \nimportant safety measure that I think the history command is missing.\n\nThanks\n\nPhillip\n\n[1] \nhttps://lore.kernel.org/git/9354d1d3-c1b7-3baf-215f-30659ad48b22@github.com/\n\n> Now the commit history is correct:\n> \n>      $ git log --graph --oneline --all\n> \n>      * 16ef548 (HEAD -> feature, main) initial commit\n> \n> \n> \n\n"},{"id":"549128","messageId":"87y0evcjpp.fsf@emacs.iotcl.com","threadId":"66031","inReplyTo":"e7dbcede-4486-459c-aa64-e44690e01fe0@gmail.com","subject":"Re: git-history(1) fixup broken with worktrees?","fromName":"Toon Claes","fromEmail":"toon@iotcl.com","sentAt":"2026-07-28T13:44:18Z","receivedAt":"2026-07-28T13:44:25Z","isPatch":false,"body":"Phillip Wood <phillip.wood123@gmail.com> writes:\n\n> I think what's happening is that the branch \"feature\" is updated because \n> the commit it points to is rewritten, but the index and working copy in \n> the work tree \"feature\" are not.\n\nYeah, it's relatively easy to understand what goes wrong, the fix would\nbe a bit more involved.\n\n> Rebase's --update-refs option refuses to update branches that are\n> checked out in other workers by default to avoid exactly this\n> problem[1].\n\nAh, thanks for finding this existing discussion, interesting.\n\n> As you can see in that thread there was some discussion about updating\n> the index and working copy when the work tree is clean instead. I\n> think that is a friendlier approach as it preserves the relationships\n> between branches and avoids materializing changes in other worktrees.\n\nYeah, I agree it would be nice if git-history(1) would give it their\n\"best-effort\".\n\n> On a related note, rebase refuses to rewrite a branch that is being \n> rewritten by another rebase running in a different work tree. That's an \n> important safety measure that I think the history command is missing.\n\nFrom [2] I've learned there are multiple ways a branch can be checked\nout. We have to take them all into account. It can be build on top of\nthe changes in that patch.\n\n[2]: https://lore.kernel.org/git/590382fb-731b-4e14-911e-ff68356d1082@web.de\n\n-- \nCheers,\nToon\n"},{"id":"550903","messageId":"aob_LsfI9cO3PewF@pks.im","threadId":"66031","inReplyTo":"87y0evcjpp.fsf@emacs.iotcl.com","subject":"Re: git-history(1) fixup broken with worktrees?","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2026-08-20T13:20:46Z","receivedAt":"2026-08-20T13:20:53Z","isPatch":false,"body":"On Tue, Jul 28, 2026 at 03:44:18PM +0200, Toon Claes wrote:\n> Phillip Wood <phillip.wood123@gmail.com> writes:\n> \n> > I think what's happening is that the branch \"feature\" is updated because \n> > the commit it points to is rewritten, but the index and working copy in \n> > the work tree \"feature\" are not.\n> \n> Yeah, it's relatively easy to understand what goes wrong, the fix would\n> be a bit more involved.\n> \n> > Rebase's --update-refs option refuses to update branches that are\n> > checked out in other workers by default to avoid exactly this\n> > problem[1].\n> \n> Ah, thanks for finding this existing discussion, interesting.\n> \n> > As you can see in that thread there was some discussion about updating\n> > the index and working copy when the work tree is clean instead. I\n> > think that is a friendlier approach as it preserves the relationships\n> > between branches and avoids materializing changes in other worktrees.\n> \n> Yeah, I agree it would be nice if git-history(1) would give it their\n> \"best-effort\".\n\nSorry, I missed this thread for quite a while. In any case, I agree that\nwe should probably do the same for git-history(1) as well and refuse\nupdating any branches that are currently checked out in another\nworktree.\n\nI've created an issue [1] for this scheduled for the next release cycle.\nHappy if anybody else beats us to it though. Thanks!\n\nPatrick\n\n[1]: https://gitlab.com/gitlab-org/git/-/work_items/772\n"}]}