Thank you! You just made me realize that there some ambiguity in the original article and thus in my reply; I have nothing against cherry-pick in git and first thought the original article was using the phrase idiomatically, as in "developers picked specific commits with their personal judgment."
The rest of this response will be written with that idiomatic reading in mind since that's what I originally intended with my criticism.
> I suspect one of the problems here is a lack of bug tracker, which would have associated the fix to the merge and the fix itself together.
I agree with this. This would make it immediately obvious that there were multiple fixes for one issue, which should be strange.
I also think there should be an overall review process where both:
1. Commits that have been chosen are reviewed by the group
2. Commits that have NOT been chosen should be reviewed by the submitters -- if there's something critical being left out, this is the time to speak up
They may already be doing something like this, for all I know, and there may be other reasons that this happened.
Additionally, I'm only coming to this conclusion because of the way it was presented in the article; the people involved may have a different view of why this happened entirely.
But for me, the way it was presented in the article, it definitely looks like a process failure.