Re: git rebase interactive breaks when working on a secondary worktree

From: Phillip Wood <phillip.wood123@gmail.com>
Date: Jun 27, 2025, 09:52 UTC
Message-ID: <073cffb5-7f15-4c41-a7ac-9f8ad1f4fffd@gmail.com>
In-Reply-To: <CACGt9y=WktE5Tqkxf6_tb_YnaeDyJTGYZoU7vErnSGnZMpuC-Q@mail.gmail.com>

On 26/06/2025 11:49, Denilson Sá Maia wrote:

Show 26 quoted lines

> git rebase interactive breaks when working on a secondary worktree
> 
> ## What did you do before the bug happened?
> 
> 1. `git clone` a repository.
> 2. `git worktree add` to have a second branch checked out in another directory.
> 3. Continue working as normal. The main branch has a bunch of extra
> commits (at the main worktree).
> 4. At the second worktree, after a while, try `git rebase -i
> hash_of_a_few_commits_ago`, or `git rebase -i main` (where main is the
> main branch at the main worktree).
> 5. Approve the plan, even without any changes.
> 
> ## What did you expect to happen?
> 
> It should work.
> 
> ## What happened instead?
> 
> I get this error:
> 
>      error: Your local changes to the following files would be
> overwritten by checkout:
> 
> Followed by a list of several files that were NOT changed in my
> secondary branch at my secondary worktree.

Do you have any line ending or filter attributes set on those files? Another possibility is that we're failing to refresh the index before the checkout. Looking at the code the index is definitely refreshed before the checkout when '--autostash' is given but I'm not sure it is otherwise.

Show 16 quoted lines

> What's more, if I redo the `git rebase` but without `-i`, it works
> fine without any errors.
> 
> ## What's different between what you expected and what actually happened?
> 
> If I try following the exact same steps (the exact same git rebase -i)
> on the exact same branch, but this time having it checked out at the
> main worktree, then everything works.
> 
> ## Anything else you want to add:
> 
> I've been hitting this error for several months.
> 
> It doesn't happen every time, it depends on the commits from both
> branches. Thus, it's hard for me to give you a minimal reproducible
> example git repository.

Unfortunately that makes it hard to figure out what is wrong.

> Given the circumstances, I believe some part of the `git rebase
> --interactive` codepath is not working correctly with worktrees, and
> thus it's misbehaving.

I'd be surprised if the fact that it was a secondary worktree was the problem. Is the worktree on the same file system as the main repository? Is the worktree synced to a cloud service?

Thanks

Phillip

Show 37 quoted lines

> 
> 
> [System Info]
> git version:
> git version 2.49.0
> cpu: arm64
> no commit associated with this build
> sizeof-long: 8
> sizeof-size_t: 8
> shell-path: /bin/sh
> feature: fsmonitor--daemon
> libcurl: 8.7.1
> zlib: 1.2.12
> uname: Darwin 24.5.0 Darwin Kernel Version 24.5.0: Tue Apr 22 19:54:29
> PDT 2025; root:xnu-11417.121.6~2/RELEASE_ARM64_T6030 arm64
> compiler info: clang: 17.0.0 (clang-1700.0.13.3)
> libc info: no libc information available
> $SHELL (typically, interactive shell): /bin/zsh
> 
> 
> [Enabled Hooks]
> applypatch-msg
> commit-msg
> post-applypatch
> post-checkout
> post-commit
> post-merge
> post-rewrite
> pre-applypatch
> pre-auto-gc
> pre-commit
> pre-merge-commit
> pre-push
> pre-rebase
> prepare-commit-msg
> 
>