Improvement: Full plan for the new Integrate Upstream button and request for deletion of local and remote branches

[peaklabs-dev]

I think I have a pretty great idea for how the new Integrate Upstream yellow button could work. This would also fix a lot of issues.

New feature (this issue): Also, I would like a new feature where local and remote branches merged into an applied branch (not only master) can be deleted in the integrate changes modal, just like they are with the blue button.

• As my workflow involves checking out a PR and then merging that PR into next (and not my current target branch main/ master), I need almost all the functionality of the blue upstream button also for my yellow button. See more about the workflow here: https://github.com/gitbutlerapp/gitbutler/issues/9739#issue-3300116784
• Basically, the yellow button could work the same way as the cyan button, with a modal that allows you to select the integration method, view all the changes and potential conflicts… but for each branch individually instead of just for the target branch.

After pulling the change, the Integrate Upstream (yellow button) appears on next (any applied branch that has changes), for example (after squash-merging a PR into it). Then, when I click the yellow button, I see the commits and multiple options in a modal just with the cyan button:

• At the top I can see all the commits, like with the cyan button. I can also see conflicts if there are any.
• Below I can select one of three integration methods (to integrate the upstream commits into the next branch):
  • Default: fast-forward merge: This just pulls and integrates all the changes without creating any commits locally. If there are local changes, stash them automatically on that branch, perform a fast-forward merge and then unstash the changes (show conflicts if there are any on a commit level). This will literally almost always work and is a much better default than rebasing or doing a full-on merge commit. This would fix https://github.com/gitbutlerapp/gitbutler/issues/8031 (a lot of this, not cyan button though) and https://github.com/gitbutlerapp/gitbutler/issues/9643.
  • Merge commit: If there are local commits committed but not pushed to the remote there is no way to do a fast-forward merge (at least I think so), so we need to add a single merge commit that can be pushed normally (not force-push). But maybe some people prefer to always do a merge commit, so it should be an option to select.
  • Rebase: If you want to rebase the branch, this is an option, but since rebasing requires a force-push, it should be the last option and certainly not the default.
• Also, as it is the case with the blue button, I can see branches that have been merged or squash-merged and delete them to clean up my workspace and local branches. This would fix https://github.com/gitbutlerapp/gitbutler/issues/9739 and my current issue (this issue) that deleting merged branches currently only works if I merge to master, and not in an applied branch in my workspace.
  • As a bonus deleting the branch also on the remote would be very cool and it would fix https://github.com/gitbutlerapp/gitbutler/issues/5508
• Also, this would allow a simple integration of removing remotes automatically for merged branches https://github.com/gitbutlerapp/gitbutler/issues/9665 -> Just show a delete linked remote next to local branch deletion option when a PR has been merged in the modal.

[Byron]

Thanks so much for the analysis, and for cross-linking the related issues!

I agree with the sentiment that there should be a choice on how to integrate. Personally I think that fast-forward should always be done if possible (and then the button should maybe be green :), but if not, there is a popup with options.

• Rebase: If you want to rebase the branch, this is an option, but since rebasing requires a force-push, it should be the last option and certainly not the default.

I think it depends. Right now maybe it takes the remote commits and puts them on top of the local unpushed ones. But it could also do the opposite and make it a fast-forward again.

This issue will help to think more holistically when it's time to tackle workspace updates and integration, see the primitives behind it, and combine them in a way that gives the user most flexibility and value.

[peaklabs-dev]

I agree with the sentiment that there should be a choice on how to integrate. Personally I think that fast-forward should always be done if possible (and then the button should maybe be green :), but if not, there is a popup with options.

Yes, that's actually a really great idea. I love this. This would be my preference as well. Most of the time, it will just work. If there are changes just stash them and then restore them. The only time fast forward will not work is if there are new local commits that have not been pushed, in which case the dialog could be shown with the merge commit or rebase option.

I think it depends. Right now maybe it takes the remote commits and puts them on top of the local unpushed ones. But it could also do the opposite and make it a fast-forward again.

This could maybe be a setting for user that prefere it like this or if you disable force pushing in the Git stuff settings it will use fast forward as that does not need a force push.

[estib-vega]

Linking the Discord thread here just in case anyone wants to jump in: https://discord.com/channels/1060193121130000425/1409913181136228503