Issue 142 forked workflow support

[martinda]

Do not merge this pull request, it is only to show the changes that would take place to support this feature. Obviously, this needs a lot more work: backward compatibility, testing, etc.

[mikesir87]

Thanks for the PR! I'm sorry I'm just getting around to it though.

I actually like this idea, as the pull request button should actually be sending the ref for the merge, not the individual branch (in my opinion anyways).

[martinda]

I am referencing the "from" but maybe I should refer the "merge". I need to study the Git plugin, and also how Stash behaves when a PR can no longer be merged due to another PR having been merged with a change that causes the first PR to no longer merge clean.

[bmoyles]

@mikesir87 @martinda Are you guys still thinking about this? We've run into similar problems with forked workflows and would love to see something like this implemented.

On whether to send /from/ or /merge/, /merge/ is only updated if a merge can be successfully completed and doesn't exist otherwise. Iff the Atlassian SDK gives one a way to determine if a given PR is currently merge-worthy, it seems reasonable to send a notifyCommit for both /from/ and /merge/ if so, otherwise just send a notifyCommit for /from/ (and perhaps also make this behavior configurable? Allow users to choose only merge, only from, or do the right thing depending on the situation)

[martinda]

@bmoyles Not for now. I find the Jenkins Git Plugin overly complicated, severely lacking in documentation and tests, and for those reasons I have concerns over its long term stability. In the mean time, I have found that for my projects, it is the /from commit that needs to be merged to the HEAD of the destination branch and be built. The /merge commit is simply a merge with an older HEAD (at the time the pull-request was made). As code gets approved and merged, Atlassian Stash does not recompute the pull-request merges with the newer HEAD. At least that is what I have found so far.