"Block Foxtrot Merges" is preventing any kind of merges if there's a merge from master to the branch
Is there a way to only prevent fast-forwards on master
in these cases?
Because a non-fast-forward merge from branch into master would never create a foxtrot merge, but it is disabled anyway, forcing a rebase (see attached image).
This happened in this example repository:
* (HEAD -> fb-EX-3, origin/fb-EX-3) Add d
* Merge remote-tracking branch 'origin/master' into fb-EX-3
|\
| * (origin/master) Pull request #2: EX-2
| |\
| | * (origin/fb-EX-2, fb-EX-2) Add b
| | * Add a
| |/
* / Add c
|/
* (master) Pull request #1: EX-1
|\
| * (origin/fb-EX-1, fb-EX-1) Add README.md
* Make initial root commit
The pull request for fb-EX-3
is unable to do a non-ff merge, or even a squash through Bitbucket Server UI.
Comments (4)
-
reporter -
reporter - edited description
-
reporter Seems related to #148
-
repo owner - changed status to resolved
Version v2020.20.17 should help here.
Historically the Foxtrot control could only be configured per-branch, but as of v2020.11.17 we’ve added an extra “push vs. pull-request” dimension to its configuration. By default now it will only trigger on pushes. For companies that fun a default “--ff” merge strategy, they can then also re-enable Foxtrot blocking for pull-request merges as well, but we’ve decided that by default to that being off, because it causes confusion and frustration for a lot of users (since most companies do not setup a “--ff” default for their merge strategy).
Blocking pushes will still stop the most common source of foxtrot merges that come via git pull’s obnoxious out-of-the-box merge behaviour: (<do work>; git commit; git push (fails, upstream is newer); git pull; git push).
- Log in to comment
For reference, if the block is disabled, this is the history after a merge (no foxtrot, first parent is preserved):