File sometimes change contents in Bitbucket Data Center source view when follow renames is enabled
プラットフォームについて: Server および Data Center のみ。この記事は、Server および Data Center プラットフォームのアトラシアン製品にのみ適用されます。
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.
*Fisheye および Crucible は除く
要約
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.
環境
N/A
診断
- 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. Prior to this, follow renames was the default behaviour of Bitbucket which can be disabled system wide using the configuration parameter commit.list.follow.renames.
- This changes the contents of the file.
原因
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.
ソリューション
Be aware of the implications on file source view of enabling/disabling "Follow Rename" option on the file history view.