Target Branch Shows Differences For Already Merged Changes Because Of Pull Request Commit ID

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

[Caroline R]

Hi, @Ali, 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

[Ali]

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.

[Sandor Huszagh]

Hi @Caroline R,

At our company, we are experiencing the exact same problem for some months now. Our process is comparable to what @Ali 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.
  
  

[Koos van Egmond]

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.

[Sandor Huszagh]

Hi. I asked a new question 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). 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

[Koos van Egmond]

Thanks for your quick feedback @Sandor Huszagh . Appreciated!