That's good work! Thank you for your effort.
On the subject of such cherry picks, I noticed not very long ago that there is a flag -x to git cherry-pick, which is supposed to be used to record its origin:
-x When recording the commit, append to the original commit message a note that indicates which commit this change was cherry-picked from. Append the note only for cherry picks without conflicts. Do not use this option if you are cherry-picking from your private branch because the information is useless to the recipient. If on the other hand you are cherry-picking between two publicly visible branches (e.g. backporting a fix to a maintenance branch for an older release from a development branch), adding this information can be useful.
That's encouraging, but unfortunately the note added by this flag is quite ugly. It's added as a parenthesis with only a single newline as a separator, which is particularly bothersome if the original commit had a single line message since e.g. git log --oneline shows it all as the title:
git log -1 --oneline
1b1124a Some bugfix with a short message. (cherry picked from commit f1055202a823fe348a4445870a791bf395b22ba3)
This is bad enough to keep me from using this feature.
If it had a better format, I'd consider using it for these merges-turned-cherry picks, and perhaps also for earlier sufficiently identical commits that have been applied to several branches (where they have been identified). Still, in theory something like it could be added later on as well by using note objects (c.f. git-notes(1)).