Confused on stash directions to solve conflicts in a merge after a pull request

[Javier Perez]

Stash gives these directions to solve a PR merge conflict

Step 1: Fetch the changes (saving the target branch as FETCH_HEAD).

Step 2: Checkout the source branch and merge in the changes from the target branch. Resolve conflicts.

This is where I'm confused. Is this not affecting the contents of my source branch?. I don't want to merge my target into my source, this can create all kind of problems for me. What am I missing?

[Marcin · Accepted solution]

Javier,

In current versions of Stash there are some scenarios (such as when creating a pull request from an older release branches to a newer one) where the instructions can be incorrect, because following them would result in a reverse merge. This is being fixed in Stash 3.6.0 (https://jira.atlassian.com/browse/STASH-5443). So if that's the scenario that you're referring to then, yes, caution is required.  In this case you would probably need to manually do the pull request merge locally (ie. merge source into target), fix the conflicts on the target, and push the changes up. Stash would detect this pull request as merged.

However in the general case, say your source branch is "my-fix" and the target branch is "master", and your source branch is branched from your target branch, then a reasonable approach to avoiding merge conflicts when merging "my-fix" into "master" is to pre-empt them by merging the latest changes on "master" into "my-fix" first, and fixing the conflicts there.  Then "my-fix" should merge cleanly into "master". This is effectively what Stash's instructions have you do.

Regards,

Marcin
Atlassian Stash 

[Javier Perez]

Thanks Marcin

[Eugene Buckingham]

Is it possible to substitute site specific merge instructions?

[Seth Carter]

bump.  Is there an answer to Eugene's question of 2 years ago?

Even if this means editing an xml on the server I would like to know.  These instructions are backwards/not correct (for us) and it is a losing battle to try and educate developers to ignore it.