git rebase interactive breaks when working on a secondary worktree

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.

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.

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

[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

On Thu, Jun 26, 2025, at 12:49, Denilson Sá Maia wrote:

A lot of hooks. Do you use git-branchless?

On Thu, 26 Jun 2025 at 17:58, Kristoffer Haugsbakk <kristofferhaugsbakk@fastmail.com> wrote:

We are using Husky in our corporate/enterprise/business application. And I think husky hooks itself into all git hooks, and that's why I have so many of them. https://github.com/typicode/husky

But inside our `.husky/` directory inside our git repository we only have `commit-msg` and `pre-push` hooks configured. Everything else is unused. (Which probably means Husky gets called, but does absolutely nothing.)

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

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.

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

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

On Fri, 27 Jun 2025 at 11:52, Phillip Wood <phillip.wood123@gmail.com> wrote:

Not sure. How can I check that?

I see this on the `local_repo_clone/.git/config`:

[core]
    repositoryformatversion = 0
    filemode = true
    bare = false
    logallrefupdates = true
    ignorecase = true
    precomposeunicode = true
    hooksPath = .husky/_

I tried removing all of the options (except for repositoryformatversion, as I'm scared to remove it). The bug is still reproducible in such case. Thus, I'm sure it is not related to these options.

How to reproduce (approximate steps):

1. The `main` branch is checked out at the directory `mainDir`.
2. Create a new worktree at `secondaryDir` for the branch `secondary`.
3. Make one or more commits on `secondary` that change a file `foo`.
4. Make a handful of commits on `main` that change unrelated files.
5. Back to `secondaryDir`, run `git rebase -i main`. (The `-i`
parameter is important to reproduce this bug.)
6. It will show a single commit to be picked. Accept the rebase plan
(save and quit the editor).

What happens:

error: Your local changes to the following files would be overwritten
by checkout:
        [It lists all the files changed by the newer commits from the
main branch.]
Please commit your changes or stash them before you switch branches.
Aborting
error: could not detach HEAD

Also, the latest commits from `main` don't need to be checked out on `mainDir`. This bug is also reproducible if `origin/main` has newer commits, but the local `main` doesn't yet. In this case, run `git rebase -i origin/main` from within the secondary branch/directory.

Hopefully these reproduction steps work better. It seems to happen relatively often (dare I say… consistently?) in this large repository from the application I'm working on. But I admit I haven't tried yet to reproduce it on a brand-new repository.

Yes, same filesystem. Both worktrees are siblings under the same parent directory.

It's a local-only filesystem, not synced to anywhere else. (Except for, obviously, `git push` and `git pull`.)