After upgrade to 7.0 I'm not able to see 3-way diff in PRs, unfortunately this is a major issue in my company, and our devs are having bad times to merge some old related branches since 2-way diff uses the common ancestor commit to show the changes.
Hi @Suporte STI the change of switching from 3-way diff to a 2-way diff is permanent. There is no configuration option that allows you to switch that behaviour.
You can find more information about that in the changelog: https://confluence.atlassian.com/bitbucketserver/bitbucket-server-7-0-release-notes-990546638.html#BitbucketServer7.0releasenotes-Amodifiedbehaviorfordiffs
Thanks,Maciej
Hi Maciej, thanks for the answer.
There is no possibility to have some action to see the 3-way diff on-demand? I understand the performance issue, but I think this is a major UX degradation, since in some complex merges, the 2-way diff become near useless. Maybe 3-way could be optional,a hidden button or something like that.
@Suporte STI
Unfortunately, maintaining the option to choose between the approaches is simply not feasible.
Foremost, let me state that our 3-way diff functionality was a feature I was, and am, very passionate about. I've defended it vigorously over the years, and invested countless hours polishing and optimizing it to try and keep it. In the end, though, I was the one who ultimately removed it. It was one of the most difficult decisions I've ever had to make, and one that I was certain would cause some end user pain.
The performance impacts of 3-way diff go far beyond the obvious, with performance issues that aren't obviously related to 3-way diff actually stemming from it. For example, having unreachable objects from pull request diffs in the repository can cause substantial slowdowns for clone and fetch operations; the server-side pack could choose those objects as bases for delta compression, which results in extensive on-the-fly repacking. (Upgrading to Bitbucket Server 6.9 or newer with Git 2.20+ on the server can help mitigate this, I'll note.)
But performance issues are really only the tip of the iceberg.
The merge-based diff has caused knock-in issues with several features we've shipped. A couple recent examples are:
It also causes a significant amount of support load due to issues like BSERV-10723. Creating the merge can fail for a variety of reasons, including changes in Git's merge behavior, submodule vagaries, long paths on Windows, and many more. In order to display conflicts in the UI, Bitbucket Server had to have logic for attempting to "resolve" conflicts so they can be committed, and that wasn't always straightforward--and when it failed, the resulting support cases were often extremely difficult to resolve.
Supporting 2-way vs. 3-way diffs as a configurable option means not only do we continue to incur all the complexity and challenges of supporting 3-way diffs, but it would also mean every feature we add would have to understand both diffs, and be able to work correctly with either.
I'm really sorry that this causes pain for your users. I truly am. But there are a lot of factors that all drove removing 3-way diffs and, with everything considered, there was broad agreement it was a necessary change to make. Perhaps, if some other work that is currently underway goes well, it might be possible to restore 3-way diffs in the future. No one would love that more than me! I can't promise that, though; only time will tell.
Best regards,Bryan TurnerAtlassian Bitbucket
Right, I really understand these points. As a last suggestion, could it be possible, at least, to have a simple diff between branches? Instead of using `git diff $(git merge-base A A` could exist a simple `git diff A B`? This could, at least, give more accurate information about the Pull Request.Sincerely, thanks a lot for your time and dedication to answer this question.
This change has been a disaster for my team. Using anything other than the most vanilla git workflow with the 2-way, 3-dot merge results in PRs with diffs that are inaccurate.This has prompted me to move our repos across to GitHub - even though we're in the middle of finalising a large release - because it's still less risky and ultimately faster than trying to work with BitBucket in its current state.
Another customer lost.
This change has significantly downgraded CI/CD procedures. It severely restricts medium to big teams to develop multiple features at the same time and be able to efficiently review the code before deployments. Also conflicts became a more painful process than ever was, thanks for that too.In my short career, It's the first time that a company decides to enforce more struggle and effort to its paying customers just to earn some imperceptible performance increase, at least to the end user, and simplify its own codebase and features.i understand the constant need for improvement to achieve better performance and lower costs, but this is definitely the wrong way of doing it, and If I may, the most lazy and unprofessional.Just a reminder of what your company's goal should mainly contribute to and why we decided to use your tools.Cheers..
This change just rolled out to my team today and it is absurdly destructive. Completely wrecks our ability to simultaneously work on tasks and have them reviewed and merged asynchronously. Now anytime trunk changes every feature branch has to be updated to see the changes. Merging trunk DOES NOT HELP.
Unbelievable honestly. Looks like we may have to leave too.
It looks like you're new here. Sign in or register to get started.
