On the pull request diff, "merged" commits are displayed as new file changes
Asked by Sandor Huszagh:

Hi,

We have been experiencing issues with our multi-branch workflow for some months now. We've never had this problem before. Even if the commits are already on the target branch, *"++merged++"* commits generated by pull requests appear as new file changes, complicating the review process. Our multi-branch workflow is (to reproduce the issue):

* For each new feature or bug fix, we create a new named **development** branch from **master** (*production*) on our repository fork.

* After we finish developing and testing, we submit a pull request, which is then merged into our **staging** branch (final test before *production*) for further testing.

* We use the **development** branch (not **staging** ) to make a pull request to **master** after testing is completed to avoid introducing additional untested fixes or changes from the **staging** branch. We merge this pull request into **master**.

* There should be no changes when we create a new pull request from **master** to **staging** at this point, but the **development** to **master** pull request's auto generated *"++merged++"* commit is displayed alongside the previously merged commits on the pull request diff. Submitting the pull request causes the "normal" commits to vanish from the list, leaving only the *"++merged++"* commit. We confirmed that the changes depicted on the pull request diff are already in **staging** , and that the "Files changed" are identical to the *"++merged++"* commit(s) shown on the commit view.  

  ![screenshot.png](/t5/image/serverpage/image-id/206300iABAB6E68B52FD101/image-size/large?v=v2&px=999 "screenshot.png")

Is anyone else having this issue? I saw a similar question, but there was no response to fix or acknowledge the problem.


Answers:
author: Theodora Boudale
body: Hi Sandor,

We recently changed our diff algorithm from what we call a '3-way' diff to a 2-way 'three-dot' diff.

The '3-way' diff included changes to the destination branch, whereas the 'three-dot' diff **does not** reflect changes made to the destination branch since the source branch was created from the destination branch. The 'three-dot' diff will show the difference between the tip of a source branch and the commit from which it branched off the destination:

* <https://bitbucket.org/blog/improving-performance-on-complex-diffs>

In order to see the changes to the target branch reflected in the diff, you can sync the target branch to your source branch. The sync can be done by merging the target branch into the source branch (locally or in the UI), or it can be done by rebasing the source branch locally. Instructions for both are detailed [here](https://bitbucket.org/blog/improving-performance-on-complex-diffs#:~:text=How%20to%20see%20changes%20to%20the%20destination%20branch%20in%20a%20pull%20request).

Kind regards,  
Theodora

comments: author: Sandor Huszagh
body: Hi Theodora. Thanks for the update!


author: Theodora Boudale
body: You are very welcome Sandor, please feel free to reach out if you ever need anything else!

Kind regards,  
Theodora


author: vkupchan
body: Hello,

We have experienced a scenario similar to the one described above, and have two follow-up questions.

1. What happens if the source branch was **not** created from the destination branch? In our case, we have multiple feature branches created from **master** , and a long-running **qa** branch, created from **master** some time ago. As we complete development for a specific feature is complete, the corresponding feature branch is being merged into **qa** . What we started seeing is bitbucket diff between feature and **qa** shows differences in files that are actually identical - can this be explained by the bitbucket diff change described above?

2. I tried to find an option for the **git diff** command that would perform the "3-way" diff, but it appears that one does not exist. Does that mean that before the change bit bucket was able to show "3-way" diff results by performing git merge without commit behind the scenes?

Appreciate any feedback!


author: Alexander Yaskevich
body: Hi. We are having exact same issue, and almost same branching model. Only instead of development branch we are using bunch of **feature** branches like *feature-1, feature-2 etc*.

I'd like to ask [@Theodora Boudale](/t5/user/viewprofilepage/user-id/818086) and community for better solution.

Can we see merge conflicts locally? Yes we can, but that makes usage of Bitbucket kind of less valuable. If not using it for team-collaboration online, then why use it anyways?

Can we merge the target branch into the source branch in UI? No we can't! That is the cornerstone of the issue.

We cannot merge **staging** branch into our **feature** branch, because then, if we merge **feature** branch into **master (production)** branch, then it will contain ++everything++ we are testing on staging right now, including ++features not ready for production++.

And since we are fully into deployment automatization, any merge commit into master branch means instant automatic deployment.

If necessary, I can provide an example in the form of public repository with several branches.

comments: author: S?tanyi B?lint
body: Hi there,

I'm having the exact same scenario and problem.

Have you managed to solve this situation, and if yes, how so?


author: Sandor Huszagh
body: Hi. The only "solution" we could come up for our specific issue was to sync the target branch (**staging** ) with **master** before every pull request. You can do it by using the **Sync** action in **Branches** . To be honest, it's not great because it takes longer than it should to do a pull request. We only send one change to **staging** at a time, so we never have problems with conflicts because **staging** and the **development** branch should always be in sync with **master**. Only in rare cases do we have more than one update in staging, and that's usually because something else is broken and needs to be fixed before the other can go through testing


author: Aviran Bergic
body: Hi! is it possible to disable it? it causes too many issues for us.

many conflicts and issues merging.

we prefer for now the latency and bad performance over the complete mess it made.

comments: author: Theodora Boudale
body: Hi Aviran,

It is not possible to disable the new diff. We have an open request to provide the preview-merge diff on demand:

* <https://jira.atlassian.com/browse/BCLOUD-21964>

You can add your vote to it (by selecting the **Vote for this issue** link) and also add yourself as a watcher (by selecting the **Start watching this issue** link) if you'd like to get notified via email on updates.

Kind regards,  
Theodora


Tags: atl-gruland

bitbucket-cloud

cloud