Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Celebration

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root

Avatar

1 badge earned

Collect

Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!

Challenges
Coins

Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.

Recognition
Ribbon

Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!

Leaderboard

Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
4,462,110
Community Members
 
Community Events
176
Community Groups

BB shows differences between branches with the same commits.

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.

2 answers

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

0 votes

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:

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

@Theodora Boudale 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

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. 

Like # people like this

Hi @adamsn82,

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.

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):

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 and we are hoping that you will be able to develop seamless workflows for your team.

Kind regards,
Theodora

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 :) 

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
CLOUD
TAGS

Atlassian Community Events