It may happen because you may assume different default behavior than YACC provides. You can refer to documentation on details of Java Regex engine defaults and available options.

Below are listed the most common cases when expected behavior may not match YACC defaults.

The . character in regex is not matching newlines

If you use a regular expression to match multiple lines of a commit message, it may not behave as expected – this is because by default in Java regular expressions the . character doesn’t match newlines.

You can work around this in two ways:

  • Explicitly include the newline character in your regular expression, e.g. (.|\n)*

  • Put (?s) at the beginning of your regular expression. This enables Pattern.DOTALL, meaning that the . character will also match newlines.

The ^ and $ are not matching every line in multiline input

By default these expressions only match at the beginning and the end of the entire input sequence. To enable Pattern.MULTILINE matching mode, add (?m) prefix to your regex. In multiline mode the expressions ^ and $ match just after or just before, respectively, a line terminator or the end of the input sequence.

Case-sensitive matching is performed

By default YACC distinguish letter cases. You can add (?i) prefix to your regex to perform case-insensitive matching.

The commit message contains unexpected text

Bitbucket automatically inserts commit summaries in pull request merges, which may complicate commit message regex checks:

Options to work around this:

  1. Disable checking of merge commits, by enabling the “Exclude Merge Commits” option.

  2. Turn off commit summaries in pull request commits (Bitbucket 6.7+) as described here.

  3. Update your regex to allow the commit summaries on pull request merge commits.