The new expected behaviour:

• If the branch model is disabled, we show instructions to manually merge the pull request.
• If the branch model is enabled and the source branch is 'stable' (production, release or develop), instructions to manually merge the pull request are displayed.
• If the branch model is enabled and the source branch is 'unstable' (bugfix, hotfix or feature), the old instructions are displayed.

+1 for this. It is very dangerous and i've had to take the step of using the hardware load balancer in front of our Stash instance to rewrite these instructions to avoid damage. This shouldn't be necessary, conflict resolution instructions depend entirely on your git workflow therefore these instructions should be configurable.

Right. I think the problem is that Stash is assuming a pull request is always promoting code up to a mainline, never merging bugfixes back to branches that are working ahead. The instructions given are only safe in the former, and violate the intentions of the Pull Request author in the latter.

If I create a Pull Request for master -> develop with conflicts and ask the dev responsible to resolve it, your instructions will advise them to merge develop -> master. Yikes.

Thanks for taking a look. I think the code review part is not as critical to us. If someone has permissions to remotely merge their resolutions to the target branch and finish the pull request, I'm okay with that.

Nick,

The issues are definitely related however STASH-5228 is a regression in functionality whereas this bug has always been the case.

The normal pull request flow is feature -> main branch. In this case showing source -> target would result in a pull request being merged, not in the conflict being resolved. If the conflict happens before the review is complete you end up with unxpected result. In your case you are using pull requests to merge release branch -> feature.

We want to make sure we show helpful instructions in both cases. We'll have to rethink how we decide which way to show the conflict resolutions for difficult categories of branches.

Jason, I think STASH-5228 and this issue are two different symptoms or manifestations of the exact same problem.

The instructions are just backwards... the conflict resolution should happen in the same direction (source -> target) as the pull request and any cascading merges that may result.

FYI, we are raising the pull request both as a method of merging and as a code review.

I've linked a related issue (STASH-5228) and have updates the titles of both bugs to better represent the issue. Rob, I believe STASH-5228 is a better description of your problem

Apologies Rob, should have checked who the author was (just saw your comment). In your case its actually a regression and is different to this bug. I'll follow up with the rest of the development team

I did not open this ticket, but I am seeing the same issue. In my case, pull requests are created from a fork into a release branch with automerge enabled. We see a conflict in the automerge from release branch to release branch. See the two screenshots I have attached. Pull request #174 shows an auto merge from 14.10.A.4 -> 15.01.B.0. The merge resolution instructions describe merging 15.01.B.0 into 14.10.A.4, which clearly is wrong.

nicku, out of interest, were you raising a pull request merely as a way to merge the bigfix downstream or was a code review performed at the same time?

Fix this please. Having these instructions wrong is very dangerous. If someone follows these flawed instructions they could really mess things up. I would change the priority of this bug to major if I could.