I am one of those who hate cherry-picking. Though both have same conflicts
and the same number of commits, merging has many advantages over
cherry-picking.
git cherry-pick creates two physically distinct commits and its very
difficult to track it over time [1].
git branch --contains commit-id can give you what all branches(or releases)
the commit is in. I personally feel this is very useful information to
have.
With merging in proper direction("tofu scale" [2]) there wont be situations
where a fix is in past release but doesn't exist in the current or future
one.
Please share your opinion on this. If everybody agrees, we can start using
this from 4.5 (ie. merge from 4.5 to master for any fixes on 4.5).
[1] http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html
[2] page 4 @
http://www.perforce.com/sites/default/files/flow-change-wingerd.pdf
~Rajani
