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

Create auto merge conflict PRs in separate branch

    XMLWordPrintable

    Details

    • UIS:
      119
    • 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.

      Description

      Problem:
      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).

      Suggestion:
      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.

      Note:
      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/").

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              Unassigned Unassigned
              Reporter:
              ronny.hanssen Ronny Hanssen
              Votes:
              69 Vote for this issue
              Watchers:
              47 Start watching this issue

                Dates

                Created:
                Updated:

                  Backbone Issue Sync

                  • Backbone Issue Sync is enabled for your project, but there is no synchronization info for this issue.