File sometimes change contents in Bitbucket Data Center source view when follow renames is enabled
Platform Notice: Data Center Only - This article only applies to Atlassian products on the Data Center platform.
Note that this KB was created for the Data Center version of the product. Data Center KBs for non-Data-Center-specific features may also work for Server versions of the product, however they have not been tested. Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.
*Except Fisheye and Crucible
Summary
Sometimes, the Bitbucket File view shows different contents when 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)
The Follow renames toggle was added in Bitbucket version 7.20+ as a fix for a similar BUG reported: BSERV-8744 - "Diff to Previous" view skips merge commit hashes in. Prior to this, follow renames was the default behavior of Bitbucket, which can be disabled system-wide using the configuration parameter commit.list.follow.renames.
This changes the contents of the file.
Cause
This seemingly strange behavior 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 the 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 a conflict resolution process), this merge commit will not be shown at the top of the history drop-down when "follow renames" is enabled even though the contents shown when you open the file in Bitbucket are from that latest merge commit. This might give the impression that Bitbucket is showing the wrong contents of the file, which is not the case.
The above behavior in no way affects 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.
Was this helpful?