On the pull request diff, "merged" commits are displayed as new file changes

[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.
  
  

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

[Theodora Boudale · Accepted solution]

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.

Kind regards,
Theodora

[Sandor Huszagh]

Hi Theodora. Thanks for the update!

[Theodora Boudale]

You are very welcome Sandor, please feel free to reach out if you ever need anything else!

Kind regards,
Theodora

[vkupchan]

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!

[Alexander Yaskevich]

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 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.

[Sótanyi Bálint]

Hi there,

I'm having the exact same scenario and problem.

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

[Sandor Huszagh]

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

[Aviran Bergic]

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.

[Theodora Boudale]

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