git-history(1) fixup broken with worktrees?

git-history(1) fixup broken with worktrees?

[Toon Claes]

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 ../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.

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?

[Phillip Wood]

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
> 
> 
> 

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

[Toon Claes]

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