Commit description not very helpful when cherry-picking a merge commit, and then cherry-picking it again
Description
Let's say you have a repo with a master
and two maintenance branches v2018.1.x
and v2018.2.x
If your repo's setting for merge requests is to make a merge commit (default)
And you use the in-Gitlab "cherry-pick" feature
Let's say you commit a maintenance bug fix into v2018.1x
, and then forward port it to v2018.2.x
(making a merge request), and then forward port that into master
What gets cherry-picked is a combined commit: merge commit and the "content-ful" commit, the bug fix
What's unfortunate is the name of the commit that goes into the later branches
Proposal
When you cherry pick a MR that originally went with a merge commit
The squashed commit description line should be from one of the "content-ful" commits
Rather than from the most recent commit (which is a merge commit, and thus its description line is "merge commit from 'x' to 'y'")
Because the description line is now, actually incorrect! It describes the lineage of the cherry pick decently well, but only if you know that's what you're looking at.
Links / references
Similar to the following issues on the CE issues, but I think I'm describing something that hasn't been explicitly hit on yet...