Target Branch Shows Differences For Already Merged Changes Because Of Pull Request Commit ID
Asked by Ali:

Hi,

As in the title I explained. Target branch shows differences for already merged changes because of pull request commit id.

Here is merge strategies that we are following :

1. "**feature**" branch created made same developments

2. "**feature** " branch merged to "**dev**" branch by pull request.

3. same "**feature** " branch merged to "**test**" branch by pull request.

Until here everything is okay. "dev" and "test" are equal.

Then I decided to develope new feature.

4. I created new branch from "**dev** "" branch let's call it "**feature-2**"

5. I made my development and I merged it to "**dev**" branch by pull request.

6. same "**feature-2** " branch merged to "**test**" branch by pull request.

In the **step-6,** Bitbucket shows changes that are already merged in **step-3**

How can we solve this problem? As our business requirement we need to follow this branching and merging strategy but it is annoying to see in every commit previous merged changes.

I think this problem is appear because of the bitbucket creates auto commit id for each pull request but still it is not make sense to see previous merged changes in every pull request.


Answers:
author: Caroline R
body: Hi, [@Ali](/t5/user/viewprofilepage/user-id/4888756), welcome to the community!

I couldn't find any Bitbucket account linked to the email you used to create this community question, so could you please confirm if the problem is related to Bitbucket Cloud or Server?

If it is Cloud, I was unable to reproduce this behavior, so can you create a test public repo and reproduce this, then share with us: (1) the link of the Pull Request with the issue (2) which exactly are the changes that shouldn't be there.

Please feel free to share any additional information regarding this case.

Kind regards,   
Caroline

comments: author: Ali
body: Hi Caroline, we are using our own Bitbucket in our company. It is installed in our datacenters/servers. Because of that I can't share you a link. It is already reachable only by VPN that's why it is not open to people which are out of the company.


author: Sandor Huszagh
body: Hi [@Caroline R](/t5/user/viewprofilepage/user-id/3934006),

At our company, we are experiencing the exact same problem for some months now. Our process is comparable to what [@Ali](/t5/user/viewprofilepage/user-id/4888756) described:

* We create a new named **development** branch from **master** on our repository fork and use it for development for every new feature or bug fix.
* After the developer test is finished, we submit a pull request, which is then merged into our **staging** branch for additional testing.
* To prevent adding anything else that the **staging** branch may already contain, we only merge the **development** branch (not **staging** ) by a pull request into **master** after the test is finished.
* Create a new branch from **master** without any change and submit a pull request for **staging** . The "merged" commits are displayed as differences. We confirmed that the changes and commits depicted on the diff are already in **staging** , and that the "Files changed" are identical to the "merged" commits shown on the commit view.  

  ![screenshot.png](https://community.atlassian.com/t5/image/serverpage/image-id/206239i096A75B2DECB6913/image-size/large?v=v2&px=999 "screenshot.png")


author: Koos van Egmond
body: I'm too experiencing the same issues lately on BB Cloud.

Let's assume we have the following branches:

* Development (D)
* Feature A
* Feature B
* Test (T)

Now A is created from D. a PR is created for Feature A which is then merged onto T.

B is started from D but is dependant of A, so A is merged into B. 1 commit is then done afterwards and a new PR is created of B. All the Changes from A are now shown in the Diff of the PR as well whereas those changes are actually already on T.

This process has been used quite a while now but seems to give these issues as of lately regarding PR diffs. This is just a simple example of a real case but we're seeing more Diffs being added up with old commits actually already merged from AND to different branches. Some diffs were even showing around 40 - 50 lines of commits where 1 or 2 commits were actually applied making the PR system unusable.  
It is as somehow the PR mechanics or merging strategy have been changed as of lately and i couldn't point out the issue yet.

the latest situation of the above case has been worked around creating the B branch of from A instead of branching of from D and merging A afterwards. This resulted in the exact same commit hashes with only the missing merge commit (obviously) so i have no clue why that helped.


author: Sandor Huszagh
body: Hi. I asked a [new question](https://community.atlassian.com/t5/Bitbucket-questions/On-the-pull-request-diff-quot-merged-quot-commits-are-displayed/qaq-p/2080354) about it, and I received an answer. To improve performance, Bitbucket switched from a "3-way" diff to a 2-way "three-dot" diff (see blog [here](https://bitbucket.org/blog/improving-performance-on-complex-diffs)). To remove these extra commits, you must first sync the target branch before submitting the pull request. It is extra work, but there is nothing else you can do


author: Koos van Egmond
body: Thanks for your quick feedback [@Sandor Huszagh](/t5/user/viewprofilepage/user-id/3129566) . Appreciated!


Tags: atl-gruland

bitbucket-server