Add support for "fast-forward merge"

[jeyj0]

Instead of the standard PR merge strategies available on GitHub (Create a merge commit, Squash and merge, Rebase and merge), we like to use a "fast-forward merge" strategy. This is sort-of like Rebase and merge, but it requires the PR's branch to already be rebased, essentially.

To execute this, we use plain git from the command line (our remote target branch is origin/dev):

git fetch
git push origin "origin/$BRANCH:dev"

Unfortunately, GitButler gets really messed up when integrating remote changes after doing such a "merge". I can't explain the whole breadth of things that can happen.

But I think those that are working on the backend will already know what the problem here is.

The simplest case (this one is easy to work around):

1. Have one open branch in GitButler
2. Create a PR for that branch
3. Merge the PR using the above git commands
4. Integrate upstream changes in GitButler

Current behavior: The branch in GitButler becomes empty.

Expected behavior: The branch in GitButler is deleted.

A complicated case:

1. Have multiple branches (branch-1, branch-2) open in GitButler (not a stack, though stacks create their own issues if I remember correctly), each with at least one commit
2. Create a PR for branch-1
3. Merge the PR using the above git commands
4. Integrate upstream changes in GitButler

Current behavior: branch-1 behaves as in the simple case branch-2 in some form shows the commits from branch-1 below it, either within its own history, or as a branch below.

[Byron]

Thanks a lot for bringing this up.

The first video shows what happens when updating the workspace right after running git push origin st-branch-41:master. It's notable that the one then integrated commit already doesn't show anymore, probably because the origin/master remote tracking branch was updated after the push, without running 'update-workspace' explicitly which would take care of removing branches from the workspace.

Then, updating the workspace somehow creates two new branches, …-42 and …-43, with the last one showing up in the workspace.

https://github.com/user-attachments/assets/11036bfa-b345-4997-8d47-87e8351c09c4

This will definitely be fixed once the workspace-update receives its rewrite.

The more complex case I didn't try as I am sure it would break in some way as well, without affecting the previous conclusion.