How to enable 3-way diff in BitBucket 7.0?

[Suporte STI]

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.

[luke]

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.

[Petros Katsaras]

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..

[David Graham]

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.

[Maciej Adamczak]

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

[Suporte STI]

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.

[Bryan Turner]

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

• Code insights: Insight analysis is posted against the pull request's source commit, but the line numbers for analysis in that commit may not match the displayed diff
• Pull request suggestions: The change needs to be applied on top of the source branch's tip commit, but the line numbers in the diff where suggestion comments are added are for the merge, not the source commit

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 Turner
Atlassian Bitbucket

[Suporte STI]

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 B) 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.

[Bryan Turner]

@Suporte STI

There's an open feature request (BSERV-7375) related to `git diff A B` versus `git diff A...B` (what we're showing) for the compare view.

A "simple" `git diff` isn't always so simple. To some extent, we're damned if we do and damned if we don't, on that. There are use cases where a `git diff A B` produces a more useful diff--but there are a lot of cases where it doesn't, too. Seeing the negation of all the changes that have been made to the target branch since the source branch diverged from it can render the resulting diff completely unusable--especially from a review perspective. Additionally, there are knock-on behavior issues we'd have to consider (if we were going to make "simple" vs. common ancestor diff mode user-selectable). For example, the system's handling for "outdated" comments, and for comments made on "Ignore whitespace" diffs vs. diffs with whitespace included, is already less than ideal. Adding in a new diff permutation with our current comment handling would just compound that confusion.

To be clear, I'm not trying to say the idea has been written off. Rather, I'm just trying to convey some of the details we'd need to nail down before we could consider it.

In the mean time, the most straightforward way to "simplify" a confusing pull request diff is going to be to merge in the target branch. At that point the source branch will be fast-forward to the target, and the only changes shown in the diff will be the actual changes. (In other words, it's effectively the 3-way diff from before, but users have to create it themselves. That's by no means ideal, and I get that, but it's at least a way to move forward.)

Best regards,
Bryan Turner
Atlassian Bitbucket

[Tim C]

This is I think the biggest loss of key, critical software functionality that I've seen in my entire history of using computers.

And, the workaround of merging the target branch first can't be done if there is more than one target branch.

This needs reverted and fixed absolutely.

[Joerg Malter]

Dear Atlassian Team,

please let the paying customers decide whether they want to use 3-way diffs or not and provide a configurable option for this.

Joerg

[Andreas Borkenhagen]

Very big loss!

[Mark Y]

How about introducing an unsupported option to bring back 3-way diff?  Then you're off the  hook for having it work properly with other stuff, but someone who wants to have this "at any price" can still do so, even if the price is "no other features work at all"

[Drew Snyder]

This completely breaks our workflow and is pretty unacceptable, imo. Funny how GitHub is able to offer three-dot or two-dot. 

[Jon Link]

This is a terrible decision and one that makes some diffs in PRs entirely unusable. Extremely disappointing decision and one that appears to be based more on what's easier for Bitbucket and less on what its customers need in order to work.

[Matthew Hartstonge]

FYI we're currently moving our whole org from BB Cloud to Github due to this... 👋😕

[Jon Link]

We might have to do the same. 

[Tim De Lange]

Would it be possible for a third party to build a plugin that gives us proper diffs?

[Paul Childs]

Goodbye Bitbucket,

This was the final nail in your coffin.

I can't risk multi-million dollar contracts on a change management system that no longer has the ability to show conflicts that might break functionality. What a monumentally moronic decision you've made.

Congratulations on increasing your performance and meeting KPIs. Hopefully the load-balancing by emigrating customers will achieve what all these enhancements have tried to do so far.

[Kyle Hoang]

This is quite painful change and breaking many project's workflow. Please make it an option instead of permanent change