Committing to one virtual branch commits to multiple

[Alxandr]

Version

0.19.5

Operating System

Windows

Distribution Method

winget (Windows)

Describe the issue

Recently, when committing changes to a virtual branch, they quite often gets committed to mutliple. For instance, here I've first committed chore: update service defaults to chore/update-service-defaults, then I've committed chore: allow disable record to chore/allow-disable-record. And for some reason it's rebased the chore/update-service-defaults branch on top of `chore/allow-disable-record.

Git log output:

at 13:02:34 ❯ git log chore/update-service-defaults
commit 5f5e5a177204d6ea30810c608d3bd1dd1ef28365 (chore/update-service-defaults)
Author: Aleksander Heintz <alxandr@alxandr.me>
Date:   Wed Mar 11 13:04:20 2026 +0100

    chore: update service defaults

commit 6bb0eb30f5929a5880d451c3606504c264f33baa (origin/chore/allow-disable-record, chore/allow-disable-record)
Author: Aleksander Heintz <alxandr@alxandr.me>
Date:   Wed Mar 11 13:05:48 2026 +0100

    chore: allow disable record

commit fa239b803d3b51d58fa19683cb46320370568c4e (origin/main, origin/HEAD)
Author: Aleksander Heintz <alxandr@alxandr.me>
Date:   Wed Mar 11 12:25:14 2026 +0100

    chore: add some logging (temporarily) (#732)

How to reproduce (Optional)

I do not know how to trigger this. It's been quite regular for me though.

Expected behavior (Optional)

Commits should just apply to one branch, and they should be unrelated to eachother.

Relevant log output (Optional)

[Byron]

Thanks a lot for reporting!

I did try to reproduce this as I thought that maybe, if there are two stacks (side-by-side) in the metadata, but in reality they are stacked, this would lead to the stacks being broken up like this which is invalid. If they are stacked IRL, they should be stacked in GitButler even if the metadata disagrees.

However, it correctly only showed one stack here as expected.

This is how it really is:

And when putting the stacks side-by-side via metadata there is only one stack, with the note that the second segment disappeared as there are more than one branches pointing to the first commit.

Here is the repository.

small.zip

Regarding the issue of "occasionally when committing, it rebases my branches", there maybe @Caleb-T-Owens has an intuition about.

[Alxandr]

A further note, this started happening a few weeks ago, so it's pretty new. Is there any sort of information/files I can provide when I manage to get get into this situation again? It happens to me every once or twice a week, so I expect I'll be able to put myself in this situation again shortly.

[Byron]

Best would be a reproducer, maybe right after it happens, recreate the situation in a demo repo if the original repo can't be shared. It's a tall order as well, so I also hope that we run into this ourselves.
When it happens, the oplog can be used to go back and forth between the good and the bad state as well, and maybe that would help to create a video.

1. run into the problem
2. revert in the oplog
3. start a screen recording
4. redo the operation manually that led to this.

That might even work, thanks for giving it a shot!

[slarse]

This description very much seems to match what's discussed on Discord here. If you can't access Discord to read the thread, the gist of it is that it's an issue with the new rebase engine that should have been fixed in the nightly (and thereby should be fixed in the next release).

@Caleb-T-Owens This seems like that same problem, right?

[Caleb-T-Owens]

Hi! This looks like a known issue with the experimental "New rebase engine" flag in the 0.19.5 release when dealing with empty branches.

Can I confirm that you have the "New rebase engine" experimental flag enabled?

Unfortunately branches that have entered this state are easiest to just finish working on them via the git CLI.

Some users have found that unapplying the stacks and re-applying them with the new rebase engine disabled also helped resolve the situation.

[Alxandr]

Can I confirm that you have the "New rebase engine" experimental flag enabled?

I do.

Unfortunately branches that have entered this state are easiest to just finish working on them via the git CLI.

I've used gitbutler for a while. Having pretty good grasp on how to fix a broken git environment was a prerequisite a good while ago, so no worries :P.