Hello, Why I find disturbing is thta the GUI does not show the good commit id used for that diff.

See that drawing I made to explain the problem (below)

At the minimum, GUI should not mislead user with that no used at all commit ID...

(as discussed here => https://community.atlassian.com/t5/Bitbucket-questions/Git-diff-show-different-files-than-PR-Pull-Request/qaq-p/2331786#U2606430)

EDIT : Oh well I cannot attach picture... See the drawing on given link...

At this stage its safe to say they would rather have you go to a competitor than fix this. I'm sure the reasoning is that they just don't think they will ever beat github or gitlab and so they are not investing in Bitbucket anymore since it isn't profitable. In the foreseeable future they will block new repos from being created like AWS did with  CodeCommit.

If you (Atlassian) don't want to change the default behaviour of the diff, then make it a setting and have the current way of doing it as the default.

Then those of us that want to diff in other ways can do so.

The options would be:

diff A...B (default)

diff A B

The diff view of a pull request must show the target branch changes that will result from merging the PR.

If the diff view shows something else, that's a bug by definition.

If it helps to increase priority, today I also ran into a incorrect diff that reported no differences between a file in two branches, but the files were different. This is very annoying because important updates where not merged into the relevant branch. We might reconsider moving all our repositories to bitbucket.

Echo on everything above.  I've already been through conversations with Bitbucket about this, but it would be disappointing if Atlassian perceived a lack of activity on this particular thread as somehow a lack of importance.   So chiming in here.

Well put by Mr. Neville – "Unfortunately for us, this inconsistency has burned hours of development time to troubleshoot and ultimately erodes trust in the system and we will be reducing our usage of Bitbucket pull requests as a result."

It seems like Atlassian is not intersted in implementing this and they might have reasons. I get that and we seem to be required to just accept it. As always in IT, proper and easy to find documentation is key for users, developers and admins.

My suggestion would be, to show direct links to the documentation on every location in Atlassian Bitbucket that shows diffs. That is, from the top of my head, the pull request diff-view and the "compare branches" view. I'm sure there is other locations as well.

In my opinion that would at least help reduce the risk of dangerously misleading people, which had happenend in my team.

It would make them think twice whether they can trust the diff they are looking at or not. For exacmple, a user who had cherry-picked changes into the target before would be warned that what they are seeing is not true / is another type of diff. Also sometimes merging in the target branch into the source in e.g a PR helps to finally get a useful and trustworthy view. It might help to include such a hint in that suggested links to the docs.

And as the original reporter of this issue implied and as it happened in my team as well. People now don't trust Atlassian diffs anymore which slows down PR reviews and making decisions. It could help to make documentation as obvious as possible for all users, even those that might not have gotten the memo...

We ran into this issue today and it took a long time to understand why the output of `git diff` and the resultant `git merge` locally was misaligned with what Bitbucket pull requests were indicating. It's incredulous to think this crucial workflow is somehow not a top priority to allow, at the very least, configurability in a drop down.

Unfortunately for us, this inconsistency has burned hours of development time to troubleshoot and ultimately erodes trust in the system and we will be reducing our usage of Bitbucket pull requests as a result.

It doesn't help if you work on performance when you can't rely on the basic functions. So you don't have your priorities right.

Currently the user selects two branches, then the tools shows the two top of stack commit IDs but below it doesn't compare these two commits, but it uses one "unknown" commit.

This behavior is simply dangerous for software development, and it doesn't help if a good performance allows you to run faster into this error.

Echoing everything in the above - this is confusing our developers and we would like to have another diff visualization that does direct branch comparison instead of going back  to the common ancestor.

I represent another large organization full of developers who don't realize that the compare view is now giving them confusing information, and sometimes not realizing it's not what they thought it was.  Even for the people who might now understand what it's actually doing, I would have to conclude that the implementation choice made here is definitely in the minority of what most people need from this.

48f8feae09ed,

We've already considered git merge-tree in the past, and it's not something we can use. While git merge-tree may sometimes be useful for certain diffs, it's not running the same merge algorithms as git merge runs (like the new ORT algorithm added in Git 2.33) and is significantly more limited in what it can produce--something its man page indicates (emphasis mine):

Reads three tree-ish, and output trivial merge results and conflicting stages to the standard output.

One particularly significant drawback of git merge-tree is that it has zero support for rename detection. If a file (or directory) is renamed (even with 100% similarity) the merge-tree diff will show the old file being deleted and the new file being added, where git merge (and our original 3-way diff) would show only the changes within the file--or potentially no content changes at all. These sorts of caveats mean that, again, while git merge-tree might work well for some merges, for others its won't. It also means there are conflicts it may show that git merge wouldn't, and vice versa.

Adding a 3-way diff view that is only useful sometimes results in significant support load from users (rightly) wanting it to be useful all the time, which is something we simply could never deliver with a git merge-tree based implementation. (Historical note: While Bitbucket Server always used git merge for 3-way diffs, Bitbucket Cloud originally used git merge-tree for theirs, before switching over to git merge specifically for rename detection. It's been several years now since they made that change.)

Best regards,
Bryan Turner
Atlassian Bitbucket

We have similar issues in our company and wanted to create a bugfix ticket yesterday. We were kindly redirected to this ticket. Although we understand your position, we might have found a command that produces the correct diffs for PRs without CPU expensive operations or even temporary commits:

git merge-tree `git merge-base feature master` master feature

Since we cannot integrate the command such that its output is displayed in the Webinterface, we'd be grateful if you take a look at it and perhaps consider it for future diff views.

Yours sincerely,

Alexander Kulow

jason.r.johnson,

In the spirit of openness and trying to ensure everyone has their expectations set, there is little to no chance the 3-way diff from 6.x and earlier will ever return. I wrote a bit about why after it happened (you may have already seen that; perhaps it's what brought you to this issue).

That said, this issue isn't (and never was) about 3-way diffs; it's about using git diff A B instead of git diff A...B for the compare view--which, if I'm honest, is also unlikely to ever change but, unlike 3-way diffs, may be something we could add a toggle for, since it's "just" a different git diff command and doesn't require the extensive (and expensive) setup 3-way diffs required.

I'm sure none of this is the answer you, or others, are looking for, but I believe it's better to be up-front about it than lead people on.

Best regards,
Bryan Turner
Atlassian Bitbucket

This has impacted us as well. Would love to see a way to bring back the 6x diff.

We also work like Marek with multiple release branches, the triple dot diff is not helpful at all under these circumstances. Perhaps you could consider a toggle between the double dot diff and the triple dot diff?

Hi bturner,

Thanks for your openness and another good explanation. And apologies for mixing the 3 way and 3 dots.... I was pretty much devastated by the news so failed to notice that.

The old way of seeing diffs in PRs was pretty much fundamental to developers workflow in our company where we strive to support customers even on older releases with new features.

Imagine that you have multiple release branches and you need to add new minor feature to few released branches.

The process that we would most often use is to create branch of the oldest release we need to push the new feature too, develop on that (often multiple commits or even sub-branches) and then we would merge that branch into the oldest release, and then merge forward to the newer and newest release branches.

Here's an example where we have a "release 1", "release 2", release 3" and "master" branch. We have "new minor feature to all" branch that has the new feature that need to be delivered to all releases. To do so, we would just create PR from "new minor feature to all" to "release 1", "new minor feature to all" to "release 2", "new minor feature to all" to "release 3" and "new minor feature to all" to "master". This would most often have no merge conflicts and would be easy to do and to review. The diff would show (thanks to you clever implementation in Bitbucket Server 6.X and older) the correct changes.

https://i.ibb.co/5x4PPgS/feat.png

Now if we use the process with Bitbucket Server 7.X the diff for PR "new minor feature to all" to "master" would show a lot of "unrelated" changes and is impossible to review. We are forced to use cherry picking and more complicated workflow where we would need to create branch for each release and merge into those and then create PRs for all of them. This is very time consuming and confusing too.

It's really sad and utterly devastating that company like Atlassian would make a major change like that without discussing with it's (major) customers first.

I (and many, many developers from my company) vote that you give us option to go back to the old and correct way of seeing diffs in PR

Regards,

Marek

marek.klus205599733,

The Bitbucket Server 7 release notes actually mention that previously the PR diff was using Three Dot diff and is now using industry standard Two Dots diff...

No, that's not accurate. The Bitbucket Server 7 release notes talk about 3-way and 2-way diffs, which does not correspond in any way to the number of dots used in the git diff command. A 2-way diff compares 2 versions of a file (either from the common ancestor and one branch tip, or from both branch tips), and a 3-way diff compares 3 versions of a file (from the common ancestor and both branch tips). git diff is only capable of 2-way diffs, and it can do them a couple different ways. Those ways are controlled by how many dots are used, with a 3-dot (but still 2-way) diff using a comparison between the common ancestor and the tip of the branch, and a 2-dot (but still 2-way) diff comparing the tips of both branches (no dots is the same as 2 dots). The 3-way diff performed for pull requests by earlier Bitbucket Server versions relies on merging the source branch into the target and then diffing the merge (so really it was the 2-way diff of a 3-way merge, and we called it a 3-way diff).

Everything in Bitbucket Server now uses a 3-dot, 2-way diff. This means compare view diffs (which have always used a 3-dot, 2-way diff, as described here on this issue) and pull request diffs are now identical.

Is there any way we can get the PR diff from Bitbucket Server 6.x back.

No. All of the logic for performing a 3-way merge followed by a diff has been removed, and we have no plans to reintroduce it. You can read this answer I wrote on Community for more details about the change, and about why it was not (and will not be) made configurable.

I realize this is a change that will affect many, and will frustrate some. I knew that before I did it, and it's still something that I think about daily. In the spirit of openness, however, I would encourage everyone to plan under the assumption 3-way diffs will never come back. It would feel misleading on my part to suggest otherwise, when we have nothing roadmapped for investing any further effort into 3-way diffs.

Best regards,
Bryan Turner
Atlassian Bitbucket

bturner - thank you for the great explanation.

However, our Bitbucket server has just been upgraded from Bitbucket Server 6.x to the latest 7.6 and there is a new PR diff behaviour that shows the Two Dot diff and it is very confusing for our developers.

 
The Bitbucket Server 7 release notes actually mention that previously the PR diff was using Three Dot diff and is now using industry standard Two Dots diff...
 
I think the diff/bahaviour that you explained by showing diff of "dry" merge is the most correct and best for developers to show the code that will get changed when PR is merged.
 
Is there any way we can get the PR diff from Bitbucket Server 6.x back.
 
Regards,
Marek
 
 
https://confluence.atlassian.com/bitbucketserver/bitbucket-server-7-0-release-notes-990546638.html
 

A modified behavior for diffs

We’ve made the switch from a 3-way diff to a 2-way diff in pull requests. This means that from Bitbucket Server 7.0 and later, when viewing a pull request, the diff shown is one between the tip of the source branch and its common ancestor with the target branch. The UI will still indicate when a pull request has conflicts, but they will no longer be marked up in the diff. Use of a 2-way diff is an industry-standard and reduces CPU load on large instances.
 

f8a128db22b8,

We already show the correct diff view; no workarounds necessary.

But no, for those who are after a point-to-point comparison (.. diff style), there's no mechanism built into Bitbucket Server for it.

Best regards,
Bryan Turner
Atlassian Bitbucket

Is there any convoluted workaround for getting the correct diff view? 

bturner - thank you for that in-depth explanation. I understand that it's difficult to find an approach that suits all expectations and that the way it is currently implemented makes sense for many use-cases.

May I just suggest as a "fix" to not call it "compare branches" or "branch comparison", or to make it clear through some other means in the GUI that what you see is the result of a a merge, and not a 1-to-1 branch comparison, or ".." or "..." comparison.

Intuitively, when clicking on something that tells me it "compares" branches, I'd expect differences from both branches to show up, and I'd expect that feature to be somewhat symmetric (comparing branch A to B should show the same changes as comparing B to A). And looking at the comments here, it appears to me that this is also what lead to a lot of confusion and frustration - changes are not showing, even though they are clearly in one of the branches.

Changing the expectations through a clearer naming might mitigate that. It's OK that this features shows what it shows, and that showing any other kind of diff would be a different feature - just name it as such.

I'm not a GUI expert by any means and probably cannot make a good suggestion. Maybe "compare merge results", "show pull request diff" etc. would be better.

Allow me to start by clearing up a misconception: Bitbucket Server's pull requests do not show a "two dot" diff, or a "three dot" diff. They show a merged diff, which is explained in more detail in this blogpost. Rather than showing a diff between the tip commits for the pull request's branches, the two branches are actually merged and then a diff is shown between the tip of the target branch and the resulting merge commit. (It's essentially a first-parent diff of the merge commit.) Since a real merge has been performed, Bitbucket Server is able to display conflicts in the diff, and "matching" changes that are already applied to the target branch are omitted from the diff.

"Two dot" diffs come with very real trade-offs. Identical changes are omitted from the diff, and that's useful. But "two dot" diffs can also end up showing negating changes for undoing changes made on the target branch, which are misleading/confusing in their own right. Consider the following:

Given a simple text file with 10 lines:

1
2
3
4
5
6
7
8
9
10

We can create 2 branches, with the following changes applied to it: (Context is set to 1 line to make the diffs smaller)

$ git diff -U1 source^ source
diff --git a/file.txt b/file.txt
index f00c965..c372ae9 100644
--- a/file.txt
+++ b/file.txt
@@ -4,5 +4,5 @@
 4
-5
+Same
 6
-7
+Source
 8

$ git diff -U1 target^ target
diff --git a/file.txt b/file.txt
index f00c965..0e88d33 100644
--- a/file.txt
+++ b/file.txt
@@ -2,5 +2,5 @@
 2
-3
+Target
 4
-5
+Same
 6

So both branches change 5 to "Same". The "source" branch changes 7 to "Source", and the "target" branch changes 3 to "Target".

Applying a "three dot" diff shows:

$ git diff -U1 target...source
diff --git a/file.txt b/file.txt
index f00c965..c372ae9 100644
--- a/file.txt
+++ b/file.txt
@@ -4,5 +4,5 @@
 4
-5
+Same
 6
-7
+Source
 8

As mentioned in the description, the "Same" change is visible, even though it's already been applied on the target branch. (In this simple case this diff is essentially identical to the source branch patch shown above, since "source^" is the common ancestor between the source and target branches.)

Applying a "two dot" diff shows:

$ git diff -U1 target..source
diff --git a/file.txt b/file.txt
index 0e88d33..c372ae9 100644
--- a/file.txt
+++ b/file.txt
@@ -2,3 +2,3 @@
 2
-Target
+3
 4
@@ -6,3 +6,3 @@ Same
 6
-7
+Source
 8

So, as expected, the "Same" change is omitted from the diff. Nice! But notice that the diff shows replacing "Target" with 3--the reverse of the change that was made on the target. That's deeply misleading, because the source branch does not change that line. Depending on how many changes have been made to the target branch since the source branch diverged, a "two-dot" diff can be extremely noisy due to negating changes–and it's generally not possible to differentiate between the negating changes and the actual changes.

As I described at the beginning, Bitbucket Server's pull requests actually merge the two branches and show the resulting diff, so let's take a look at that:

$ git checkout -b merge target
Switched to a new branch 'merge'

$ git merge source
Auto-merging file.txt
Merge made by the 'recursive' strategy.
 file.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

$ git diff -U1 target merge
diff --git a/file.txt b/file.txt
index 0e88d33..48f3cad 100644
--- a/file.txt
+++ b/file.txt
@@ -6,3 +6,3 @@ Same
 6
-7
+Source
 8

In the pull request diff, then, you don't see the "Same" change, but you're also not misled by the fake "Target" change. In this example, at least, it's the "best" diff--it shows exactly what will change, and nothing more.

Compare doesn't use a merge-based diff for performance reasons. Pull requests rely on some complicated server-side caching to display their diffs, and they provide a well-defined lifecycle (meaning the server knows when a pull request is "done" in a way it doesn't with ad hoc comparisons).

None of that resolves this issue, of course, and no doubt some will still feel a "two dot" diff is "better" in this context. Hopefully, though, this at least provides some useful context for explaining why the system does what it does, and why it is, in fact, a "big thing" to try and change it. There's no git diff command the server can run that produces the diff we show for pull requests without the system having to perform the merge first, and a "two dot" diff is by no means a straight "improvement" over a "three dot" diff.

Best regards,
Bryan Turner
Atlassian Bitbucket

I had the same issues. Their seems to be a need for your customers to have a branch compare. Maybe you think about simply implementing one instead of arguing with your customers for 4 years. Couldn't be a big thing.

2 people lost couple hours to investigate the cause of invalid diff between two branches! This one is BUG! Not a suggestion! In case of PR I probably agree that three dots is better maybe . But in case of 2 branches it's 100% BUG. If you don't want to fix it - tell me where the config is located so I can change to two dots. Or provide workaround!!!

We are having the same issue. We basically tell our folks the compare feature is not reliable and inaccurate. When we reported it to the Atlassian Support, they basically told us the Bitbucket is doing it correctly. It's not a bug even though it contradicts with the files shown in the branch view, served directly from Bitbucket GUI. 

Needless to say, we are very disappointed with the response we got from Atlassian Support when they suggested closing the support ticket and redirect us to this Jira. Given that this ticket was opened for >3 years with zero movement, I highly doubt this will be resolved any time soon.

We ended up running the diff using the Git command. No pretty GUI, but at least we are serving the correct difference between two branches.

We have just had the very same issue. At the time I was not aware of this bug and did not believe it at first because this is common functionality that I expect to work out of the box. Now I am in the position where I can not rely on Bitbucket and the information that it is giving me.

Atlassian, please jump this up to a critical priority and fix it!

We just installed Bitbucket server 5.9.0 still the same issue.

Support can you make it more clear in the UI 

Yes, I've just had the same discussion in the Atlassian Support Desk, and I also think that at the least there is a UX issue, in that there are two "Diff" screen that show you different information with no visual clues that something has changed.
1- When creating a PR, diff view is ... to common ancestor.
2- When PR is created, diff view is now a view on the merge commit.
the only real way to see this, is to click on Blame, and then notice that the commit hashes don`t match, before and after the PR is created.
it would be nice to see a cleaner UI cue what is being diffed.

It seems that we get hit by this every three months.  

The most interesting case was my manager trying to compare two branches to make sure his changes to both were applied, but since the diff is actually against a common ancestor, it made it look like they weren't.  

The easiest thing to do short term is some kind of GUI element showing what is actually being diffed.  That will go a long way to explaining to a user what's going on.

Longer term, it would be nice to be able to select what kind of diff is done.

That document doesn't match the behaviour of the diff view in this case, sadly.

with the ultimate goal of providing an overview of which changes will be merged when a merge is performed

Bitbucket's diff view also shows the changes on the target branch that have happened since the feature branch was created. This includes more changes, which leads to the confusion.

It also gives an example of an equivalent git command using two dots:

git diff source_branch_B..target_branchdiff --git a/file1.txt b/file1.txt

However, Bitbucket's behaviour is equivalent to using three dots.

Had a meeting with our Atlassian TAM on the subject. He provided an incredibly helpful doc that explains exactly how the diff view works:

https://confluence.atlassian.com/bitbucketserverkb/understanding-diff-view-in-bitbucket-server-859450562.html

This explains a lot of the oddities teams were seeing at my company. While I'm not sure this is always the best model for showing a diff, I accept it, and am working with teams so they don't run into this issue.

Still occurs on latest Bitbucket Sever.

Just ran into this with two teams at my company. We also opened a support ticket earlier, and we were told it's working as expected, and to raise requests for a new feature. 

For us, the big confusion is git diff shows properly while Bitbucket server did not. We'd like parity between the client and server tools.

We also had cases here where users couldn't understand what was going on, and being puzzled by the fact that two branches (one of them in a fork, so not that easy to check using the command line) behaved differently, even if the "diff" was telling them that there was no change... Cue hours lost finding the problem. We were just lucky that this didn't cause serious problems in production.

So please, the two methods are fine, just make them explicit and user-selectable.

We are also experiencing similar problems. I used to rely on the Bitbucket compare tool, but now I can't trust it. I hope we get a fix to this soon, but it seems that this issue is not getting much attention. Can this be prioritized high on the list please? Thanks.

I totally agree, that it is quite misleading and confusing. Our development team has also complained about it and that it gives
the impression that more has changed that they actually changed.  
I have logged support item here: SSP-18684 that goes more in detail into the problem.
P.S the support item is not public but Atlasian will be able to access it to get more details. 
It would be really great if this could be fixed or like mentioned above a consistent DIFF is used in PR and PR Preview to prevent confusion.

The current behavior is definitely unexpected and confusing. At least provide the option to choose a diff algorithm when comparing branches.

This messes us up regularly. As the Atlassian's blog suggests, there is is a better way: https://developer.atlassian.com/blog/2015/01/a-better-pull-request/

That is a totally misleading behavior! The fact that diff in PR is different than a diff in PR preview seen on a previous screen seconds ago is laughable at best. Please fix

I'm +1 for some kind of configuration capability to pick the diff mode used in the pull request preview, See STASH-7522.

git diff in three dot mode is useful to see what changes have been made to the feature branch since it diverged from the development branch.

git diff in two dot mode is useful when there are similar changes applied to both branches and you want to see the net effect of merging the feature branch back into the development branch.

Note that once the pull request has been created it only shows the two dot version so we are instructing our users to skip the preview step and review the pull request after it has been created.