search

isaacs / github

Just a place to track issues and feature requests that I have for github
2.2k stars 129 forks source link

Update Branch button settings: allow choosing merge strategy #1419

Open GrayedFox opened 5 years ago

GrayedFox commented 5 years ago

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:

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:

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 :bowtie:

tgsmith61591 commented 5 years ago

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

GrayedFox commented 5 years ago

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 commented 5 years ago

+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 commented 5 years ago

Just sent them another email. 😄

michalschott commented 4 years ago

Any update on this please?

JoaoFGuiomar commented 4 years ago

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

sielay commented 4 years ago

Or just disable "Update Branch" as https://github.com/lnfnunes/404-PageNotFound/issues/98 tried to achieve. It causes more mess than benefits.

themightychris commented 4 years ago

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 commented 3 years ago

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

eyalroth commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

@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 commented 3 years ago

@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 commented 3 years ago

@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 commented 3 years ago

Any update on this?