You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
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.
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
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.
@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.
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.
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.
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,
A bitbucket fan :)