"Diff to Previous" view skips merge commit hashes in

Summary

When viewing a file's "Diff to Previous", the file is diffed against the first non-merge commit hash in 4.6.0 as opposed to 4.5.2 where it is diffed against the merge commit hash.

Steps To Reproduce

Set up a remote git repo in both Bitbucket Server version 4.5.2 and 4.6.0 that consists of both push and merge commit hashes similar to this network graph:

Commits are the same in both 4.5.2 and 4.6.0:

Expected Results

"Diff to previous" view for the view should be the same in 4.5.2 and 4.6.0

Actual Results

"Diff to Previous" view is different in 4.5.2 which diffs the file against the changes contained in the commit with the hash that corresponds with the merge:

whereas in 4.6.0, the merge commit has is skipped and the file is diffed against the first non-merge commit hash:

Cause

The reason for this behavior is due to how git handles the --follow flag, which is what Bitbucket uses to handle renames within the system.

Workaround

Disabling the rename tracking functionality globally by adding the following to your $BITBUCKET_HOME/shared/bitbucket.properties will allow these commits to be seen as expected:

• commit.list.follow.renames=false