Virtual branch should be removed if there are no changes

[koppor]

Version

0.13.0

Operating System

Windows

Distribution Method

msi (Windows)

Describe the issue

When a PR was merged upstream, the virtual branch was not removed while syncing:

I re-created the PR at JabRef/jabref#11919

See: 0 files changed!

---

I think, gitbutler should remove virtual branches with 0 changes.

How to reproduce

(I am guessing, reproducing is hard. If you need a "strong" reproducer, I can try to create an MWE repository)

1. Work on a virutal branch
2. On GitHub: create a commit on main
3. Push the branch
4. Create PR
5. On GitHub use "update branch"
6. GitHub creates a merge commit
7. "Update" workspace
8. On GitHub: Merge PR
9. "Update" workspace
10. See that branch "fix-typo" is not gone

Expected behavior

Branch with 0 changes gone.

Relevant log output

No response

[Byron]

Thanks a lot for reporting!

It seems the issue here is that GitButler doesn't detect if the commits in a virtual-branch were already integrated. Thus, it would allow the creation of a 'new' PR which doesn't actually contain line-changes that aren't merged into the target branch yet.

When looking at the commits in the PR and trying to find them in main, I was unable to find a match though. It's like the commits are duplicated and have the same content. Probably I am missing something here or it's too late for me 😅.

[koppor]

When looking at the commits in the PR and trying to find them in main, I was unable to find a match though.

Oh, this is an easy one: We do squashing to have a smaller commit history. 😅

[Byron]

That's interesting!

Even though the algorithm to figure out if a local branch is merged or not is quite elaborate, I'd be a little bit surprised if it could detect that it would be able to detect this on hunk level. In a way, it would have to make a test-merge and only if it comes out without any changes, we'd know the hunks are already present in the target branch.

It's the question, if I am not missing something, if one should go that far, after all the two histories would be unrelated after the squashing.

[koppor]

Even though the algorithm to figure out if a local branch is merged or not is quite elaborate, I'd be a little bit surprised if it could detect that it would be able to detect this on hunk level. In a way, it would have to make a test-merge and only if it comes out without any changes, we'd know the hunks are already present in the target branch.

The alternative is to be aware of GitHub's commit messages for Suqash-merged-PRs:

The pattern is to reference the PR number in braces at the end of the commit message.

Since GitButler knows the PR number for a virtual branch, it could just check if main contains a commit referencing this PR.

As a double check, it could see if the changes of the virtual branch matches those of the commit.

---

Self-advertisting: I do that kind of parsing in my GitHub Contributors List tool, where I build a table of all contributors based on the commits of PRs linked by that number.