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.