Right now, cherry-picking via the GitLab GUI seems pretty broken. It appends to the commit message some informative text[1] like:
"
(cherry picked from commit 273eb06390821597d632606587ad79a8e152e122)"
Which is reasonably helpful enough, but adds the two blank lines, not just one[2], in recent cases I've tested. The extra blank line causes it to fail the "git stripspace" check in tools/
validate.commit.py and thus fail the pipelines. There's no way around this from the GUI, since the commit message is automatically created. Changing the merge request message doesn't affect the commit itself; the cherry-picked branch can be pulled and altered on the command line, but one might as well just use the CLI for all of the cherry-picking instead of GitLab's GUI.
Checking, I see that this has hit other people as well:
Another irritating thing I have found with cherry-picking into multiple branches (e.g., release-3.4 and master-3.2) from the original wireshark repository is that GitLab automatically names cherry-pick branches using only the commit name but not the target branch.[3]
What's worse is that if I create a cherry pick branch for release-3.4, and then immediately go back to the same commit in wireshark master and try to create a cherry-pick branch for master-3.2, I get an error in the GUI like:
"A branch called 'cherry-pick-e42cc671' already exists. Switch to that branch in order to make changes"
If I slightly vary things and create one cherry-pick from the main GitLab repository's master and the other cherry-pick from my local fork of master, then I do get two branches, one named 'cherry-pick-{hash}' and the other named 'cherry-pick-{hash}-2'. I'm not sure where I'd turn to get a cherry-pick into the target master-3.0. Perhaps cherry-picking a cherry-picked commit.
Has anyone else run into this, and do you have a workaround? Our existing workflow has been built around cherry-picking, and this makes it harder.
John Thacker
