Uploaded image for project: 'Bitbucket Server'
  1. Bitbucket Server
  2. BSERV-4837

Create auto merge conflict PRs in separate branch



    • UIS:
    • Feedback Policy:
      We collect Bitbucket feedback from various sources, and we evaluate what we've collected when planning our product roadmap. To understand how this piece of feedback will be reviewed, see our Implementation of New Features Policy.


      When a cascaded auto merge has conflicts a new PR is created. This sounds fine, but there is a major flaw with it when the target release branches have permissions that restricts access to these branches - which was the main reason why we chose to use Stash in the first place.

      The current solution in Stash expects the developer to resolve the conflict on the target branch using the suggested procedure in the conflict warning message in the PR. However, when the developer has resolved the conflict he may not be allowed to push his changes - as they are done directly on the target branch (which may have write restrictions).

      To overcome this the conflict resolution should be done in a branch that developers have write access to and not on the target branch. That branch should then after resolution continue auto merged (like the current cascaded auto merge system does).

      So, when there are conflicts on a cascaded auto merge Stash should:

      1. Create a "proxy" branch based on the tip of the target branch.
      2. Create a PR from the source branch to the proxy branch.

      The developer then resolves the conflicts on the proxy branch, where they have write access.

      Stash should then:

      1. Close the proxy merge PR (nothing to merge from source - just like the current automatic merge failure PRs closes when resolved).
      2. Try to merge the proxy into the target. This will normally just work. If the PR is closed before any other commits has been done on the target branch then this would be a fast forward of the target release branch. If the target release branch has newer commits then in most cases the merge would probably be without conflict. In the rare occasions where this conflicts again, then Stash should just create a new conflict PR.

      This is what we are now doing, but manually and with a little extra pain. When a cascaded auto merge fails, we follow the procedures for fixing the conflict, except we create a proxy branch that we fix the problem in. We then manually create a PR for this. When that merges to the target the automatic merge failure should be clean and dismissed. We sometimes just manually fail this as well.

      I'd suggest that these conflict-branches where created with a prefix to allow for permissions on these separately (i.e. "conflict/").


          Issue Links



              Unassigned Unassigned
              ronny.hanssen Ronny Hanssen
              68 Vote for this issue
              48 Start watching this issue