Option to Cherry-Pick commits for Automatic Merge

I like the idea of enabling Automatic Merge of on release branches back to the main development branch, but in practice I find that it does not work as well as I had hoped.

The problem is that I will create a release branch off of our main development branch, and will make a few tweaks to the build configuration files, specific to the release under preparation. Some time later, I may commit a bug fix, which I also want committed back into my main development branch. I have enabled the automatic merge feature, but when I commit and merge my bug fix through a pull request, it opens a new Pull request merging the entire release branch back into my development branch. This means all the configuration changes that were made to prepare the release branch are now getting targeted into the main development branch, which could cause issues with clobbering over a release (through mvn site-deploy) if gone uncaught.

Perhaps it is an issue with the way our code is organized, but I feel like we can't be the only team hitting this type of issue?

It seems like one possibility, would be to open a new Pull Request that cherry-picks just the commits that were part of the bug fix pull request.

Likewise, sometimes you know that the commit going into a release branch cannot be merged as-is back to the development branch, so it would be great to be able to deselect specific branches from having a PR opened. For example, say you have a bug fix pull request targeting release/1.2.0, and the result of the Automatic Merge is that it will trickle down into release/1.2.1, release/1.3.0, and master:

#!text

release/1.2.0 (target of PR)
|-- release/1.2.1
|--|-- release/1.3.0
|--|--|-- master

You can see all these branches in the Pull Request Merge dialog when Automatic Merges are enabled, but there is no way to de-select release/1.3.0 and master branches from obtaining the fix. In some cases you may be dealing with a bug fix that was only applicable for a couple of releases.