+1 +1, also for the assembly of subscribers of the thought -"one of those who hate cherry-picking".
To voters of "Cherry-pick" - Merge and Cherry-pick are not even comparable when it comes to managing and fixing the issues in multiple branches. "git branch --contains" or "git tag --contains" give the right information about to which all branches/tags a particular fix is ported (unless someone deviated from default merging strategy of git). No other model would be that viable. "cherry-pick" should not be intended, rather should not be hacked to address this. Thanks, Vaibhav -----Original Message----- From: Rajani Karuturi [mailto:raj...@apache.org] Sent: 31 October 2014 12:35 To: dev@cloudstack.apache.org Subject: [DISCUSS] merging vs. cherry-picking 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
