Are you in the loop? Keep up with the latest by making sure you're subscribed to Community Announcements. Just click Watch and select Articles.

Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


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


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. 

3 answers

1 accepted

2 votes
Answer accepted
Theodora Boudale
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
Jul 18, 2022

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:

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,

Hi Theodora. Thanks for the update!

Theodora Boudale
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
Jul 19, 2022

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

Kind regards,


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!

Like # people like this

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.

Hi there,

I'm having the exact same scenario and problem.

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

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

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
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
May 12, 2023

Hi Aviran,

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

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,

Suggest an answer

Log in or Sign up to answer
AUG Leaders

Atlassian Community Events