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
Community Members
Community Events
Community Groups

How to enable 3-way diff in BitBucket 7.0?

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.

1 answer

1 vote

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:



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.

Like # people like this
Bryan Turner Atlassian Team Mar 25, 2020

@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 behaviorsubmodule vagarieslong 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

Like # people like this

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.

Like # people like this

@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

Like Mark Y likes this

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.

Like # people like this

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.


Like # people like this
Like # people like this

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"

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

Like Andreas Borkenhagen likes this

Suggest an answer

Log in or Sign up to answer
Community showcase
Published in Bitbucket

Git push size limits are coming to Bitbucket Cloud starting April 4th, 2022

Beginning on April 4th, we will be implementing push limits. This means that your push cannot be completed if it is over 3.5 GB. If you do attempt to complete a push that is over 3.5 GB, it will fail...

2,235 views 2 9
Read article

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you