Summary

Sometimes Bitbucket File view shows different contents by clicking on the same latest commit shown from the history drop down when follow renames is enabled.

Environment

NA

Diagnosis

• Open the file in question from Bitbucket Source view inside the Repository.

• This will show the contents from the latest version of the file along with the commit id as shown below.

• Next from the History dropdown select the same/latest commit id. (notice that the follow renames toggle is enabled)

• This changes the contents of the file.

Cause

This seemingly strange behaviour is because of how git shows file commit history. 
When viewing a git file commit history with follow renames you will not see merge commits in the list. (See below example)

• When viewing git file history without the follow renames merge commits are shown.

• However when viewing it with the --follow option it does not show the merge commit.

As shown above this is an inherent git behaviour which is also shown in Bitbucket.

Hence if changes to a file are introduced during a merge commit (like during conflict resolution process), this merge commit will not be shown on the top of the history drop down when "follow renames" is enabled even though the contents being shown when you open the file in Bitbucket are from that latest merge commit. This might give an impression that Bitbucket is showing wrong contents of the file which is not the case.

The above behaviour in no way effects the state of the repositories or the file contents in git.

Solution

Be aware of the implications on file source view of enabling/disabling "Follow Rename" option on the file history view.