Different file content for the same commit is being displayed in Bitbucket Server
Platform notice: Server and Data Center only. This article only applies to Atlassian products on the Server and Data Center platforms.
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
Problem
Bitbucket Server shows a different content for the same commit hash of a file when accessing from the Commits page and by browsing to the file in the Source page.
Diagnosis
Diagnostic Steps
Expected change displayed
Commit page
The commit page, accessible at the <BITBUCKET_URL>/projects/<project_key>/repos/<repository_name>/commits/<commit_hash>
, shows the expected change.
Source page (with commit_hash)
The source page, accessible by browsing from the Source tree and selecting the item from the History drop down, and therefore resulting in a URL similar to <BITBUCKET_URL>/projects/<project_key>/repos/<repository_name>/browse/<path_to_file>?until=<commit_hash>&untilPath=<path_to_file>
, shows the expected change.
Not expected change displayed
Source page
When the source page is accessed by browsing the Source tree, and therefore the URL is similar to the following <BITBUCKET_URL>/projects/<project_key>/repos/<repository_name>/browse/<path_to_file>
, an unexpected change is displayed.
Case 1 - "Evil Merge" scenario
Cause
An "evil merge" has been performed in Git. Because of this operation, the commit is not linked to the file path and cannot be retrieved when accessing it from the path.
An evil merge is a merge that introduces changes that do not appear in any parent. For performance reasons, Git does not try to find which path these changes belong to.
In order to prevent these problems when merging, only select content that came from one of the branches in the merge. Then fix any compilation errors and test failures in a separate commit. This ensures that git can trace the changes of each path.
Workaround
There is no workaround available to recover this problem, apart from reverting the merge commit. New commits will not be impacted by any "evil merge" in the history of a file.
You can find out which merge introduced changes to the file by running git log
in the repository and search for the path of the file that seems to have different content. There should be a merge commit with the file listed under Conflicts
, it will be after the last commit to the file path (shown by git log – <path to file>
).
Case 2 - Presence of a tag with the same name as the branch being viewed
Cause
For Bitbucket Server versions earlier than 6.8.0, this issue can be caused by a tag that has the same name as the branch currently being viewed, but is pointing to a different commit from the branch head.
Example:
- The source file in the "master" branch is being viewed.
- However, there is a tag named "master" that points to an earlier commit from the branch head.
- In this case, the file content that will be shown in the Source page will be the contents pointed to by the "master" tag.
This is due to the following bug, which is fixed in version 6.8.0:
BSERV-12033 - Getting issue details... STATUS
Workaround
Delete or rename the tag that has the same name as the branch.
Alternatively, upgrade to Bitbucket Server 6.8.0 or later.