Junio C Hamano <gits...@pobox.com> writes: > Sergey Organov <s.orga...@javad.com> writes: > >> Nope. It seems like cherry-pick takes care of that: >> ... >> What do I miss? > > The fact that cherry-pick did not flag it as a potential conflict > situation where a manual verification is required > (the cherry-pick process can be fooled by textual similarity and > either add the same thing twice or fail to add one thing that is > needed).
Well, it was not required in the simple case I tested, and cherry-pick did the right thing. I suspect it will do the right thing (flag a conflict) where manual verification is required. A test-case demonstrating the problem you have in mind, maybe? Anyway, how is it different to cherry-pick merge commit compared to any other commit? I mean, provided we cherry-pick other commits, we already accepted all the possible negative consequences of cherry-picking. How cherry-picking merge commits make this worse? I.e., do you think we have a show-stopper, or just that there are ways to handle merge commits event better than simple "cherry-pick -m1"? The latter is probably true, but simple cherry-pick still looks much better than what we have now, no? -- Sergey. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
