BB shows differences between branches with the same commits.
Asked by Claudio Valderrama:

Hello, since a few days we have the following problem that we don't remember having faced in years: we have the master branch for production and the "cert" branch for QA. A developer makes commit/push of their changes in their private branch (one branch per issue) and asks for a pull request to cert, then it's merged, installed and tested by QA. Once it's approved by QA the same commit is used to produce a pull request to master. We have worked this way for years. Now we see that after having merged the same changes in cert and master, a comparison between cert and master shows the changes are not in cert, but we see the commits and the merges in cert. Our only solution has been to destroy "cert" and create it again from master several times a day but this is becoming tiresome. Also, yesterday we experienced an outage where the BB web interface froze when creating new branches and this lasted for a few hours. We are surprised we don't see any problem in the status page. Thank you.


Answers:
author: Jeremiah Fulbright
body: We are struggling with this change as well, as it is now unreliably showing us merge conflicts exist, but not showing us what they are.

We use the level of merge conflict to determine if the developer will be resolving or if the Deploy Master can do it, if it is minor. This is now a headache for our entire process.

Thankfully we're moving away from here


author: Theodora Boudale
body: Hi Claudio,

We recently made changes to the diff algorithm from what we call a '3-way' diff to a 2-way 'three-dot' diff:

* <https://bitbucket.org/blog/improving-performance-on-complex-diffs>

When viewing a pull request or comparing branches, the diff shown is one between the tip of the source branch and its common ancestor with the destination branch.

It is possible that what you are reporting has to do with this change, however, it is difficult to say for sure if we don't examine an example.

I see that you are a member of a workspace on a paid billing plan, so I would suggest creating a ticket with the support team the next time you experience this issue. If there is a support ticket open, the engineer working on the ticket will be able to access the repo and diff in order to investigate.

You can create a ticket via <https://support.atlassian.com/contact/#/>, in "What can we help you with?" select "Technical issues and bugs" and then Bitbucket Cloud as product. Please make sure to provide the URL of the repo where the branches are compared and also mention which of the changes you do not expect to show in the diff.

Kind regards,  
Theodora

comments: author: adamsn82
body: [@Theodora Boudale](/t5/user/viewprofilepage/user-id/818086) Is anyone else struggling with this change? We are looking at moving all our repositories to GitHub because the pull requests are no longer reliable per your own articles.

[The diff in pull requests is showing unrelated files after upgrade of Bitbucket Server or Data Center to 7.x or 2-way diff change. \| Bitbucket Data Center and Server \| Atlassian Documentation](https://confluence.atlassian.com/bitbucketserverkb/the-diff-in-pull-requests-is-showing-unrelated-files-after-upgrade-of-bitbucket-server-or-data-center-to-7-x-or-2-way-diff-change-1063162552.html)

*In case of the conflict not shown in the UI, you need to clone the repository locally and with the usage of git diff identify the conflict.*


author: Theodora Boudale
body: Hi [@adamsn82](/t5/user/viewprofilepage/user-id/1871076),

Let me begin by saying I am sad to hear that you are struggling with our latest changes to the diffs. Please let me clarify that while we were proudly the sole source code management tool in the industry that supported the preview-merge diff, it was very significantly impacting the performance we were able to deliver to our customers. The complexity to calculate the preview merge diffs is the very reason why other SCM providers made the choice never to even introduce them to their customers.

While the preview-merge diff showed the changes made to the destination branch in the diff, if the feature branch was not synced with the latest from the target branch, then the feature branch code was not tested with the latest target branch code.

In order to see the changes to the target branch reflected in the diff, simply sync the target branch to your feature branch. The sync can be done by merging the target branch into the feature branch (locally or in the UI), or it can be done by rebasing the feature branch locally. Instructions for both are detailed [here](https://bitbucket.org/blog/improving-performance-on-complex-diffs#:~:text=How%20to%20see%20changes%20to%20the%20destination%20branch%20in%20a%20pull%20request).

We have a feature request for building an option to request the preview-merge diff on demand (in this case, conflicts will show in the '3-way' diff):

* <https://jira.atlassian.com/browse/BCLOUD-21964>

You can add your vote to that feature request (by selecting the **Vote for this issue** link) and also add yourself as a watcher (by selecting the **Start watching this issue** link) if you'd like to get notified via email on updates.

The article that you linked in your response is referring to Bitbucket Server and not Cloud. However, it provides details about the same changes we have implemented in Cloud. These changes do not mean that pull requests are no longer reliable, we have changed our diff algorithm from a '3-way' diff to a 2-way 'three-dot' diff.

With making these changes to the diffs we are now able to give you a boosted performance and we also continue to work on additional features that should help your internal workflows. Please feel free to monitor our [public roadmap](https://www.atlassian.com/roadmap/cloud?selectedProduct=bitbucket) and we are hoping that you will be able to develop seamless workflows for your team.

Kind regards,  
Theodora


author: John Verzijden
body: Hi, Same issues here. I hope by now you guys will have acknowledged that this is a real problem. The diff is an important part of our quality process too. Being the first doesn't gives you an advantage. I'm afraid you'll will have to keep up with the standard you've helped to set. If the new way doesn't work and can't be repaired quickly, seems to me the solution is to role back and improve first. Performance was an issue for sure, but not sure this makes it better. It could create doubt of the quality of bitbuckets core product.

If it the issue was solved by now, good for you :)

With kind regards,

John Verzijden

A bitbucket fan :)


author: Pawel
body: Just stumbled upon this problem as well, when I was comparing changes in our release branch to master.

"When viewing a pull request or comparing branches, the diff shown is one between the tip of the source branch and its common ancestor" - this doesn't make any sense. When you are reviewing a pull request you are interested in the impact this PR will have on the target branch, not what was the history of development (if it's a feature branch you could simply have a bunch of "correct typo", "revert" commits).

Your suggested workaround (just sync it with your target first, duh ...) is not a feasible solution if you have a release branch that accepts only some bugfix commits (cherry-pick, or done directly by patching) from other branches.

At least an option to chose between \`git diff HEAD..origin/master\` and \`git diff HEAD...origin/master\` should be available.

BR,

Pawel


author: Theodora Boudale
body: Hi Pawel,

Thank you for the feedback. We have a request to show the preview-merge diff on demand: <https://jira.atlassian.com/browse/BCLOUD-21964>

You can add your vote and feedback to this request, and add yourself as a watcher if you'd like to get notified via email on updates.

Kind regards,  
Theodora


Tags: bitbucket-cloud

cloud