Control Freak Regex is checking while merge rather than push

[Former user]

Control freak is stopping me to merge rather than push My Regex: [[Ss]print:(PI)?\d\d.\d:(US)?([Ss]tory):?\d{2,10}:(Complete|InProgress|Inprogress)]\s{1,}.{5,}\s* My Commit Message: [Sprint:18.1:Story:12345:Inprogress] – Adding PI18 to HaloB orch build.I18 to HaloB orch build. I thought this regex will be checked while i push but when i create a pull request i get a merge conflict because of the regex. I have attached the screenshot of it, please check and let me know if this is an expected behavior or bug. I'd prefer to have the push trigger the regex instead of the merge – is there a way to configure that?

[Julius Davies [bit-booster.com]]

The answer to your question is a little complicated. Short version: Control Freak is behaving correctly (this is not a bug).

The "Match Regex" rule will trigger for all commits coming into any of the branches the "Jira Policy" is configured to protect. You would need to review your repository's Control Freak configuration itself to see which branches are currently configured to require "Jira Policy".

The branches with checkboxes here (see the config screenshot - look for “Apply Jira Policy Against”) become the "protected" branches:

Pushes to protected branches will trigger the check, and block the push if the commit does not comply with the regex.

Pushes to unprotected branches will not trigger any checks.

But pull-requests from unprotected branches into protected branches will get blocked (merge will not be allowed).

The moment a commit crosses over from an unprotected branch into a protected branch the rule will trigger. Usually that transition happens because of a "git push" (commits on your local machine are never protected by Control Freak - it cannot see them!). But if the transition is occurring because of a proposed pull-request merge, then it will trigger then, blocking the merge.

If you check all the "Apply Jira Policy Against" boxes (e.g., [x] Default [x] Development [.....] [x] All Others), then it will trigger for all pushes to all possible branches (including new branches that will be created from the push). That might be what you want!

(Note: forks are still considered unprotected, so pull-requests from forks will still trigger the check.)