ControlFreak foxtrot PR interaction problem

Issue #172 resolved
Jim Howard created an issue

Our development team has recently started using ControlFreak, and have found it to be extremely helpful!
We've encountered one serious difficulty with this plugin, however. The foxtrot merge prevention checks are excellent, but the way they interact with pull requests are problematic (and this has unfortunately caused us to deactivate the foxtrot checks wholesale, since it prevents us from doing legitimate work). The issue is caused by the apparent assumption that the PR branch will be merged without the default --no-ff option, and would therefore cause foxtrot merges to be created in certain (but for us, fairly common) circumstances. By policy, we always merge to "upstream" branches using the --no-ff merge option - which is also the default option to Bitbucket’s PR Merge methodology - and of course this policy makes creation of a foxtrot merge impossible. And yet the otherwise legitimate PR is blocked by ControlFreak because of this incorrect assumption.
As mentioned, this unfortunate interaction has required us to disable this otherwise very useful foxtrot merge functionality.

This looks to be completely related to both Issue #148 and #167.

Comments (1)

  1. Julius Davies [bit-booster.com] repo owner

    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 decides to 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).

  2. Log in to comment