Diff view in Pull requests shows incorrect and misleading information

Question

Bitbucket server version 5.5.3

The diff view when comparing two branched in depot sometimes gives false information that I can`t understand.

Here I list the two branches in question, the version number in each file, and the diff comparisons with the diff client in git bash.

Finally, I`ve added two images from the diff view in bitbucket that show a different value. The "to" value in the bitbucket diff view is correct, but the "from" value is incorrent which is misleading.

It looks as though the behaviour between git-diff and diff view in bitbucket is inconsistent.

branch 1: master

branch 2: feature/add-boostrap-3.3.7

Content of the file package.json at head of each branch.

$ git checkout feature/add-boostrap-3.3.7
Switched to branch 'feature/add-boostrap-3.3.7'
Your branch is up to date with 'origin/feature/add-boostrap-3.3.7'.

$ more package.json
{
"name": "tiweb.static.libs",
"version": "1.2.0",

$ git checkout master
Switched to branch 'master'
Your branch is up to date with 'origin/master'.

$ more package.json
{
"name": "tiweb.static.libs",
"version": "1.1.2",

Preview of the diff in each direction

$ git diff feature/add-boostrap-3.3.7..master package.json
diff --git a/package.json b/package.json
index b5d51c5..b1dca15 100644
--- a/package.json
+++ b/package.json

{
 "name": "tiweb.static.libs",
- "version": "1.2.0",
+ "version": "1.1.2",

$ git diff master..feature/add-boostrap-3.3.7 package.json
diff --git a/package.json b/package.json
index b1dca15..b5d51c5 100644
--- a/package.json
+++ b/package.json

{
"name": "tiweb.static.libs",
- "version": "1.1.2",
+ "version": "1.2.0",

So far, this all seems correct.

Image for the same diff in bitbucket

The images show values that don`t exist in either branch (but they are most likely previous values in the files in question.)  The nature of that value changes often so it`s hard to reproduce. but it seems to be something along the lines of two files changing the same value away from the common ancestor value. and then chanching back to a new value, that both files share. i.e. both branches change to the same value independently.

it`s important to  note that this error does not always happen. but when it does, it`s very confusing.

adelobosko · Answer

++ with Ryan McCullough

Could you implement the diff comparison in this way?

Adam Hughes_jf2zbx · Answer

I 100% agree wtih Ryan McCullough.

This issue has caused us to think code was missing in envs where it had been deployed, causing us to rebase and do all sort of unnecessary triaging.  We've been doing a large migration and changing our branching model, and this has made that effort much worse.  To find out it was introduced as a way to improve peformance is really annoying.  I'd much rather my PR's take 5 minutes to merge than them to behave as they do now.  Furthermore, not showing conflicts in BB and instead just pointing out the conflict file names feels like a step backwards.

Ryan McCullough_samu0a · Answer

I see the same issue. I'm told that this is, contrary to popular opinion, a feature, not a bug, and this is explanation that I received:

I'm logically unable to connect to a realistic scenario where anyone would want to see this as the default path for comparing branches.

The compare tool gives you the option to select branches, but I don't think its really doing that (especially given the commit has it shows next to the destination branch); It seems like its actually comparing the destination branch as it was in the most recent merge point in the history of the source branch.

I feel like people typically care about now, and what's happening now; And they're concerned with how compatible a branch from right now is with the master of right now, not three months ago, or whatever.
I feel like people would find it forthright to find that commit, make a branch of it and  perform a diff, rather than the compare feature that we have now.