When automatic merging between release streams fails due to a merge conflict, frequently commits from other pull requests stack up behind the commit which initially failed to merge forward. Because those subsequent commits are often made by other users (with the merging of their own separate bugfixes), our company likes to have the author of the conflicting commit merge just that commit and no commits following it that are stacked up in the merge failure pull request. By taking this strategy, if there are multiple conflicting commits due to different features merging, each author is responsible for merging their own feature forward, then passing control of the conflict resolution to the next author.
A pain point with this conflict resolution workflow is that when the original author eventually merges his or her conflict resolution into the destination release stream, the automatic merge conflict pull request reflects the fact that the oldest commits have been "removed" from the pull request, but automatic branch merging does not continue -- even if the next few commits are conflict-free and automatic merging could have continued successfully. Is there a way to trigger a new attempt at automatic branch merging when conflict resolutions merge into the destination release stream? I'm imagining that the branch merger would walk through the oldest commits in order until it hits another conflict or successfully merges all changes so we don't have to do this manually within our organization.
