-
Notifications
You must be signed in to change notification settings - Fork 128
Update Branch button settings: allow choosing merge strategy #1419
Comments
@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. |
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 ;)
|
+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 |
Just sent them another email. 😄 |
Any update on this please? |
This would be a very interesting option to have. 🍻 ☝️ |
Or just disable "Update Branch" as lnfnunes/404-PageNotFound#98 tried to achieve. It causes more mess than benefits. |
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 |
Another 👍🏼 for this, we have a policy of requiring fast-forward merges and this big inviting button can cause problems. |
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:
|
@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 |
@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:
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). |
@eyalroth You're leaving out the quite common scenario where one branch is just simply ahead of the other branch. For example, if With GitHub's hardcoded insistence of 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. |
@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. |
Any update on this? |
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: :bowtie:](https://github.githubassets.com/images/icons/emoji/bowtie.png)
The text was updated successfully, but these errors were encountered: