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

From: Denilson Sá Maia <denilsonsa@gmail.com>
Date: Jun 27, 2025, 11:42 UTC
Message-ID: <CACGt9ym5+YFGMvqN_mnfa8T_+0u3asXWeCrD-SstvQxfmN1aOg@mail.gmail.com>
In-Reply-To: <073cffb5-7f15-4c41-a7ac-9f8ad1f4fffd@gmail.com>

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

>
> Do you have any line ending or filter attributes set on those files?

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.

Show 5 quoted lines

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

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.

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

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

> Is the worktree synced to a cloud service?

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

-- 
Denilson Figueiredo de Sá Maia
https://denilson.sa.nom.br/