Phillip Wood <phillip.wood123@xxxxxxxxx> writes: > I can see why people want to revert merges but cherry-picking them > always feels strange to me - what is the advantage over actually > merging the branch and seeing the full history of that commit? One case that comes to my mind is when you failed to plan ahead and used a wrong base when building a series to "fix" an old bug. You built a 7-patch series to fix a bug that you introduced in release 1.0, but instead of basing the fix on maint-1.0 maintenance track, you forked from the tip of master that is preparing for your next feature release that is release 1.4. Even if you realized that the fix is important enough to warrant applying to the maint-1.0 maintenance track, you cannot merge the topic that houses 7-patch series down to the old maintenance track without bringing all the new features that happened since 1.0 on the master track. A kosher way may be to rebase the 7-patch series to maint-1.0 and merge the result into the maint-1.0 track (and upwards if needed). But cherry-picking the commit that merged the original "fix" topic into master _may_ be simpler, as you need to resolve a larger conflict but (hopefully) only once, instead of up to 7 times, once per each commit on the "fix" topic while rebasing. But of course if something goes wrong, it makes the result impossible to bisect---exactly the same reason why you should think twice before doing a "merge --squash". In addition, if you somehow figured out why the cherry-picked fix was inadequate, you'd now need to forward-port the fix for the fix to the master track or whereever the cherry-picked-merge was taken from. On the other hand, if the original "fix" branch was rebased on maint-1.0 and then further fixed, the result can be merged to maint-1.0 as well as all the way to the master track. So, I can understand why people may want to cherry-pick a merge, I suspect it is a false economy. Optimizing for picking, paying higher price when the result of (incorrect) picking has to be corrected later.
