feat(gitlabPrService): auto-remove source branch on MR creation

[nolith]

Add removeSourceBranch option when creating merge requests to ensure the source branch is deleted automatically after the MR is merged. This helps with PR Stacks because every time the bottom merge request is merged, the next one in the stack will automatically change its target branch to main/master.

🧢 Changes

Add the removeSourceBranch option when creating merge requests to ensure
the source branch is deleted automatically after merging MR. This
helps with PR Stacks because every time the bottom merge request is merged, the next one in the stack will automatically change its target branch to main/master.

☕️ Reasoning

📌 Todos

Unfortunately, I was not able to validate this change on my workstation. When I compile GitButler with pnpm dev:desktop, the "Create Pull Request" button is completely unresponsive with or without this PR applied.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
gitbutler-components	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Apr 23, 2025 9:10am

[vercel]

@nolith is attempting to deploy a commit to the GitButler Team on Vercel.

A member of the Team first needs to authorize it.

[krlvi]

@nolith I remember discussing this with somebody on discord - I think there was an API that we can use to query what the repository has been configured with on GitLab, this way we could use the configured value, instead of hard-coding to true.

[nolith]

@krlvi yes you can GET /projects/:id and look for remove_source_branch_after_merge to see the configured value (I'm not sure if you can see that if you are not a maintainer).

However, stacked MRs don't work without that setting, as you merge your first one (MR1), the second merge request (MR2) will be merged to the first branch instead of master/main.

Moreover, the diff on the second one is all messed because as soon as you update and force push on GitButler, your MR2 is now rebased on master, but the target branch (MR1) is not because Gitbutler thinks it is integrated and no longer touches it. At this point, your MR2 diff will show all the new developments in master and your code.

[krlvi]

@krlvi yes you can GET /projects/:id and look for remove_source_branch_after_merge to see the configured value (I'm not sure if you can see that if you are not a maintainer).

However, stacked MRs don't work without that setting, as you merge your first one (MR1), the second merge request (MR2) will be merged to the first branch instead of master/main.

Moreover, the diff on the second one is all messed because as soon as you update and force push on GitButler, your MR2 is now rebased on master, but the target branch (MR1) is not because Gitbutler thinks it is integrated and no longer touches it. At this point, your MR2 diff will show all the new developments in master and your code.

Okay this is reasonable.

Of course, it would have been nice if we could make the behavior be: "if there is no stacking, use the value from remove_source_branch_after_merge otherwise if there is more then one branch in the stack always set removeSourceBranch to true".

However... since this removeSourceBranch is set on branch creation, there is no way of knowing if the user intends to stack branches on top. So yeah, let's make this always be true.