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

[Phillip Wood <phillip.wood123@gmail.com>]

Hi Toon

On 17/07/2026 19:54, Toon Claes wrote:
> 
> 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/

> Now the commit history is correct:
> 
>      $ git log --graph --oneline --all
> 
>      * 16ef548 (HEAD -> feature, main) initial commit
> 
> 
>