In this page

Logging

The Better Commit Policy app records its internal activities to a so-called log. The log helps you to understand the activity of the app when diagnosing problems.

Viewing the log

The Better Commit Policy app writes its own log lines to the Bitbucket log:

  1. Find the logfile named atlassian-bitbucket.log (see the guide by Atlassian).
  2. Search for the text "com.midori" to find the lines written by Better Commit Policy.
  3. If you can't see any log line written by the app, check if DEBUG logging is configured correctly, then use the corresponding app function again.

If you can't interpret the log lines you found, report it to our support. We are there to help you!

Configuring logging

When investigating a run-time problem, you may need to increase the logging level for the Better Commit Policy app. Doing so, it will write more details about what it does to the log, which helps you understand the problem.

How to enable DEBUG-level logging

To turn on DEBUG logging via the Bitbucket REST API without stopping Bitbucket:

  1. Open an operating system console (command-line).
  2. Execute this command (using the proper parameters): 
    curl -u <admin_username>:<admin_password> -v -X PUT -d "" -H "Content-Type: application/json" <bitbucket_base_url>/rest/api/latest/logs/logger/com.midori/debug
  3. Check if a line like this appears in the Bitbucket log: 
    2019-09-10 16:15:31,768 WARN  [hz.hazelcast.event-3]  com.midori Switching to log level [debug]

Alternatively, to increase the logging level permanently (i.e. even if Bitbucket gets restarted later):

  1. Stop Bitbucket.
  2. Edit the $BITBUCKET_HOME_DIRECTORY/shared/bitbucket.properties file (create the file if it doesn't exist yet).
  3. Add the following line and save: 
    logging.logger.com.midori=DEBUG
  4. Start Bitbucket.

Now execute the app function that you think fails, then check the log for the details.

Typical problems and their solutions

My push is rejected with the message "Too many commits found, retry with smaller data! (max. 1000 accepted in one batch)"

You're likely trying to push (or merge) an unexpectedly large number of commits in one go.

Solution 1: Push the changeset in multiple parts

The app is designed to strictly verify every single commit before accepting it. In order to keep the server stable, it imposes a limit of 1000 for the number of commits that are processed in one push.

The solution is simply splitting the "mega-push" into multiple smaller pushes, each containing max. 1000 commits. As explained in this article, Git allows pushing commits up to a certain commit (defined by its hash). If you have e.g. 2500 commits to push, you can use this method to split those to 3 separate batches.

In the following section, we give a step-by-step guide for this. Please note although that the steps are explained with the Git commandline client, it is possible to adapt these to your favorite Git client, too. It is just super-easy with the commandline client.

Steps:

  1. Determine the hash of the 1000th commit to push by using this command (Linux/bash syntax): 
    git --no-pager log <REMOTE>/<REMOTE_BRANCH>..<LOCAL_BRANCH> --oneline --reverse | head -n 1000 | tail -n 1
    For example, if you try to push from your local master branch to your origin's master branch: 
    git --no-pager log origin/master..master --oneline --reverse | head -n 1000 | tail -n 1
    It will show the hash of the 1000th commit, for example: 
    108a04ca Fix for the killer bug FOO-123
  2. Warning! If you haven't received the hash, then the root cause is different, see fixing the default branch!
  3. Use this commit hash to tell Git up to which commits to push: 
    git push <REMOTE> <LAST_COMMIT_HASH>:<REMOTE_BRANCH>
    In our case: 
    git push origin 108a04ca:master
  4. Push the "remaining" commits simply by: 
    git push
    If it is rejected because you still have more than 1000 commits, then go to step 1 to push the next batch.
    If it is accepted, then you are done. Congratulations!
Solution 2: Fix the default branch in Bitbucket

A non-existing default branch may cause unexpectedly detecting that you are pushing more than 1000 commits, while you are not. This usually happens after importing a repository which uses a main branch with a different name.

If your repository is not empty, go to Repository settings → Repository details → Default branch and choose an existing branch.

In rare cases, it may occur that the repository is empty, you're experiencing this problem, but you can't navigate to the screen where you could fix the default branch. To work around this, disable the Commit Policy Verification hook in the repository, push at least one commit to the default branch. Now, the repository is not empty any longer, so you can fix the default branch and re-enable the hook!

My push is rejected with the message "Access key "Access Key User - john.doe@acme.com" is not allowed to push commits."

You're trying to push commits using an SSH access key set up for system use, while Better Commit Policy for Bitbucket is configured to reject all commits pushed by external systems.

See the corresponding configuration guide.

I see an error message "An error occurred while processing the request" at pull requests.

Secondary symptoms: the spinner of the "Merge" button does not stop and an exception was thrown in PullRequestService.canMerge().

This is caused by a minor Bitbucket bug (BSERV-10045) which was fixed in Bitbucket 5.4.0.

You can safely ignore the red error message: it is harmless and it is displayed only once. Just reload the page in your browser to make it disappear. And then as an actual solution, upgrade to Bitbucket 5.4.0+.

Questions?

Ask us any time.