Diff not being correctly rendered, and branch showing as "integrated" when it isn't

[boc-the-git]

Version

0.13.1

Operating System

macOS

Distribution Method

dmg (Apple Silicon)

Describe the issue

Note: actually deployed via homebrew.

The symptoms I'm seeing is that my diff is inaccurate (I changed ~4 different sections, not the one shown in the screenshot), and that after making my commit the branch shows as integrated.. I haven't even pushed this remotely.

The file I'm changing on branch C was also modified on branch A, which was merged into main hours ago. I have not updated the workspace since that. I'm assuming this is the root cause of the problem, but it's a horrible and confusing UX.

When I expand branch A (having seen the "1 change" message), it looks to include the rest of the missing diff from branch C.

Hopefully that makes sense?

Note branch B has no relevance to the file/issue.

How to reproduce

Not 100% certain, this is what I think has happened:

1. Have a virtual branch where you change a file (we'll call X)
2. Merge that branch to main
3. Start modifying X again locally and pop it on a new virtual branch
4. Make a commit

Expected behavior

I'd expect to have just had my file with its entire diff on branch C and none of this mess with branch A. After performing the commit on branch C I should've got the normal "push" option, rather than this "integrated" view.

Relevant log output

N/A

[boc-the-git]

I'm able to relatively easy straighten this out by updating the workspace.. it had a conflict on branch A due to the weirdness.. I used the stash option to make it go smoothly, and copied my changes back into place.

[boc-the-git]

Sorry, probably not my greatest ever bug report 🙈 Hopefully those replication steps work for easily enough though.

[Byron]

Thanks a lot for reporting!

I didn't try to reproduce the issue, but wanted to add that maybe this code is related:

https://github.com/gitbutlerapp/gitbutler/blob/3bd4428f3586981f9afcd058a38c1f5d3e433de4/crates/gitbutler-branch-actions/src/virtual.rs#L375-L377

It's trying to determine if a commit looks the same, despite not being the same, based on message, author and committer, and I always thought that this might backfire in some way with false positives. Please let me state again that this might be entirely unrelated to the actual cause of the issue, but if you wanted to try this locally, it would be enough to default copied_from_remote_id to false to see if that affects the classification of commits in this case, should it occur again.