There's many cases where I need to cherry pick a patch to more than one branch. It'd be really useful (especially now gerrit will do cherry picks even if they conflict, and just leave the conflict markers in place) if I could specify multiple branches, ie REL1_35, REL1_37, REL1_38 to be cherry picked in one go.
Description
Event Timeline
The REST API is https://gerrit.wikimedia.org/r/Documentation/rest-api-changes.html#cherry-pick which takes as in put a CherryPickInput entity. It only supports a single branch.
That can surely be amended by committing some resource and time to get Gerrit to support that new feature. Then it is unlikely anyone at upstream would be interested in spending time on it (maybe @Paladox might?).
To explain a bit more why it might not be of much interest to them. The way upstream manage their stable branch is they do the fix on the earliest branch (REL1_35) then once reviewed and merged they merge the hotfixed stable branch to the other stable branches all the way up to their primary branch which results in something like:
* (master) merge REL1_38 into master * (REL1_38) merge REL1_37 into REL1_38 | \ | * (REL1_37) merge REL1_35 into REL1_37 | \ | * (REL1_35) Hotfix for issue 1234 ... * (master)
If the fix has first been proposed to the primary branch, it has to be moved to the earliest stable branch (ex: REL1_35) merged there and then it get merged back up. Or in short I don't think they cherry-pick.
That being said, a script can probably be written which would take a list of changes as parameter then issue the rest api querry to cherry-pick a change against each of the branches.
Even though it takes one, you can foreach over an input that cherry-picks but doesn't go to it but rather reloads the page at the end.
Even though it takes one, you can foreach over an input that cherry-picks but doesn't go to it but rather reloads the page at the end.
Possibly yes. Also a one click button cherry picking could trigger multiple conflicts which would need to be handled and displayed to the user. It is probably not that straightforward to implement in Gerrit.
I am declining this task, reflecting I don't think we can easily implement it.