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
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.
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.
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.
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.)
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.
Hi everyone, The Cloud team recently announced 12 new DevOps features that help developers ship better code, faster ! While we’re all excited about the new improvements to Bitbucket ...
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