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

Question

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.

Koos van Egmond_1fhh3f · Answer

Thanks for your quick feedback @Sandor Huszagh . Appreciated!

Sandor Huszagh · Answer

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_1fhh3f · Answer

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.