Update Branch button settings: allow choosing merge strategy

[GrayedFox]

As a GitHub repository owner and administrator, if there are no conflicts with the base branch, I would like to be able to decide the merge strategy used for the Update Branch button available to contributors from one of:

• fast forward merge
• normal merge
• rebase and merge

As a GitHub contributor, if there are no conflicts with the base and the base branch doesn't enforce a particular merge strategy, I would like to be able to choose my own preferred merge strategy for the Update Branch button from one of:

• fast forward merge
• normal merge
• rebase and merge

This is a related but separate feature request related to #1169 and #1113 author: the latter which is about availability of the update branch button, but which has a hot comment relating to the nature of this feature request.

+1 comments are evil. Use your thumbs people, not valuable screen space

[tgsmith61591]

@GrayedFox did you email [email protected] about this? Curious what their response was, if so. My team and I have been griping about this recently.

[GrayedFox]

They confirmed that it's something they've passed onto their product team - I'll have to dig it up - but I got the feeling I wasn't the first to raise the issue. Feel free to email them too and link back to the thread! Gotta keep that pressure on ;)

[mixja]

+1 for the fast forward merge - it would mean I can preserve artifacts built and tagged with feature branch commit hash during PR checks and deploy them into production

[GodloveD]

Just sent them another email. 😄

[michalschott]

Any update on this please?

[JoaoFGuiomar]

This would be a very interesting option to have. 🍻 ☝️

[sielay]

Or just disable "Update Branch" as lnfnunes/404-PageNotFound#98 tried to achieve. It causes more mess than benefits.

[themightychris]

Yes please at least let repo administers disable the "Update branch" button. On projects with a policy of rebasing feature branches it is a constant menace

[mjftw]

Another 👍🏼 for this, we have a policy of requiring fast-forward merges and this big inviting button can cause problems.

[eyalroth]

I don't see how fast-forward should be an option here (only merge commit and rebase). Fast-forward is only relevant on the merge to the base/target branch, not when updating the source branch.

Possible flows:

1. Update source branch with merge commit from target -> merge PR with merge commit.
2. Update source branch with rebase on top of target branch -> merge PR with merge commit to the target branch.
3. Update source branch with rebase on top of target branch -> merge PR via fast-forward of the target branch.

[vdh]

@eyalroth Some of us would prefer to use a fast-forward merge without doing any rebasing at all. Fast-forward does not go hand-in-hand with rebasing, they're two separate mechanisms in Git and it's frustrating to have people dismiss it as if it were something only relevant to a rebase.

Fast-forward merges happen by default in Git when a regular merge commit isn't required. It's only this weird hardcoded-into-GitHub default of always using --no-ff for everything that has kicked the humble fast-forward to the curb.

[eyalroth]

@vdh In my understanding, a situation where the source branch of a PR has to be updated due to changes in the target branch, will only happen when the two branch diverge; i.e, both the source and target have at least one commit that doesn't exist in the other branch:

A - - - C  (target head) 
  \
    \
      B  (source head)

In such state, it is impossible to fast-forward in either direction.

In order to "unite" the two branches back together, without deleting the diverged commits, one has to either use a merge-commit or rebase (and then either ff or not).

[vdh]

@eyalroth You're leaving out the quite common scenario where one branch is just simply ahead of the other branch. For example, if develop has just been merged into master, and you want to then update develop to the latest commit on master (i.e. the merge commit you just made).

With GitHub's hardcoded insistence of --no-ff, attempting to make this update in the UI would create yet another merge commit (an empty one), instead of simply fast-forwarding the older branch to be up to date with the newer one.

Now, some people may actually want this empty commit for either feature tracking or workflow purposes, or to trigger CI checks. But it's frustrating to have a normal part of Git's behaviour locked out from the user interface.

[eyalroth]

@vdh I believe the scenario you are describing is not relevant to the "update branch" button/feature, which is aimed at already opened PRs with newly introduced commits on the source branch.

It sounds to me that this scenario perhaps deserves its own feature, and might not even require a PR as no new commits are introduced to the repo.

[SpootyMcSpoot]

Any update on this?