GitButler thinks branch is not incorperated upstream.

[Icantjuddle]

Version

Version 0.14.19 (20250428.160452)

Operating System

macOS

Distribution Method

dmg (Mac OS - Apple Silicon)

Describe the issue

After merging a PR made with gitbutler using the squash and merge strategy on github, my local gitbutler client will not remove my local branch and rather thinks it is conflicted.

How to reproduce (Optional)

1. create a PR with with gb
2. Merge with squash and merge and delete the branch on github
3. Update workspace on local gitbutler

Expected behavior (Optional)

It recognizes that the branch is incorporated upstream and offers to delete the local branch.

Relevant log output (Optional)

[Byron]

Thanks a lot for reporting! It seems that the failure to detect that the branch is already integrated allowed to perform a rebase which then had to cause a conflict. I hope we can tackle this in the next major release.

[Icantjuddle]

Is there a better way to work around this thank to manually fixup the .git/gitbutler/virtual_branches.toml to make it forget about it?

UI operations seem to end up in some loop of conflicted states that cannot be resolved?

[Byron]

Altering the configuration file directly might be possible - there are flags for whether something is integrated or not. Maybe @krlvi can advise?

[krlvi]

I have an idea for approaching this.

The root cause here is that whenever there is a squash commit, it is difficult to recognize that the branch that is still in the workspace is indeed integrated - the commits will be different, and the commit message of the squash commit is not reliable either.

The app also looks at the content - i.e. "does the incoming version contain the exact code that is in the branch". But if there were follow up changes, e.g. the branch was squash merged but then the code was modified by another merged PR it can no longer detect it.

--

So I am thinking about implementing a "treat as integrated" override option for the workspace update operation. This override can be triggered by the UI, based on the Pull Request status.

This solution is a little bit cheating because it would not work universally, especially if a person does not have a forge integration enabled. But maybe helping some of the cases is better than helping none

[Byron]

I like this approach, i.e. also to use other signals to determine if something is merged. This was also my feeling when integrating the data types as the frontend uses them with the data that is actually present, and a couple of states aren't currently handled that may relate to whether or not something is integrated.

Over time, we should be able to chip away at this problem, one test at a time.

[MFattakhov]

Hey! Any updates on this issue? Anything we can do locally with some file tweaking?

[Byron]

I'd expect this to be better very soon thanks to algorithm change.

[peaklabs-dev]

I did some testing with the new workspace backend turned on but most of the time, when I unapply a squash merged branch via unapply stack, it still does not recognize the changes are now integrated on the workspaces via the also applied next branch in the workspace and then it moves the changes to unassigned even though they are not unassigned anymore.

[Byron]

Thanks for sharing!

Since unapply/apply aren't yet on the new backend, they may often see the world differently, yielding inconsistent results. My apologies.

[MFattakhov]

This week at the last version I managed to correctly incorporate squashed merged pr, thx for the fixes. Is the issue not fully done?

[Byron]

Thanks for letting us know :)! Happy to close this issue now.

[MFattakhov]

Unfortunately it broke on an in-progress stack merging :( At a 5 height stack it firstly showed:

After I merged first PR in github via squash-merge button gitbutler showed this:

Have you experienced correct behavior while testing? Maybe the problem is that i started working on a stack on the old backend?

[peaklabs-dev]

Yes and unapply stack also does not support squash merged PRs yet see https://github.com/gitbutlerapp/gitbutler/issues/8457#issuecomment-3150058908

[Byron]

That looks all kinds of wrong. The traffic-light buttons are misplaced, and the integrated branch says it's "Unpushed". Unfortunately I had exactly the same just now but didn't manage to debug it. Instead I hit the push button and now it's considered integrated as is expected.

The issue here seems to occur after the update workspace button was pressed. Are you using the new workspace backend?

If so, is it doing better if that option is turned off? Generally I'd recommend not to press that button while there are stacks applied if possible, or to use the Operations History (Cmd + Shift + H) to get back to a good state afterwards.

[MFattakhov]

Sorry for the traffic lights, I have a 14" macbook and the stack didn't fit fully, so I just zoomed out.

Yes, I am using the new backend, don't actually know why it says unpushed, I guess it's because of the top commit.

Cannot actually see benefits from the new backend in this case :(

[MFattakhov]

So I've tested the most basic case:

Before: squash-merged first branch in github but not updated the workspace

After: tried to update the workspace

what's good: first branch is gone, bad: don't know what to do with these upstream commits that are actually incorporated

[Byron]

That's a great test, and definitely a shortcoming in the squash-detection. But I think this can be fixed, and I'd hope that this can be made more robust as well.