Different file content for the same commit is being displayed in Bitbucket Server

お困りですか?

アトラシアン コミュニティをご利用ください。

コミュニティに質問

プラットフォームについて: 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 は除く

問題

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.

診断

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

原因

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.

回避策

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

原因

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.

例:

  • 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

回避策

Delete or rename the tag that has the same name as the branch.

Alternatively, upgrade to Bitbucket Server 6.8.0 or later.


最終更新日 2021 年 4 月 30 日

この内容はお役に立ちましたか?

はい
いいえ
この記事についてのフィードバックを送信する
Powered by Confluence and Scroll Viewport.