Hi Elijah, On Wed, 20 Mar 2019, Elijah Newren wrote: > On Wed, Mar 20, 2019 at 8:09 AM Sergey Organov <sorganov@xxxxxxxxx> wrote: > > > > Junio C Hamano <gitster@xxxxxxxxx> writes: > > > > [...] > > > > > But I do have a very strong opinion against adding yet another > > > option that takes an optional argument. If we want to allow > > > cherry-picking a merge commit just as easy as cherrry-picking a > > > single-parent commit, "git cherry-pick -m merge" (assuming 'merge' > > > is the tip of a branch that is a merge commit) that still requires > > > the user to say "-m" is not a good improvement. We should just > > > accept "git cherry-pick merge" without any "-m" if we want to move > > > in this direction, I would think. > > > > Let's just make '-m 1' the default option indeed. No need for further > > complexities. > > > > Exactly according to what Junio has already said before. Here: > > > > https://public-inbox.org/git/xmqqsh5gt9sm.fsf@xxxxxxxxxxxxxxxxxxxxxxxxx > > > > Junio wrote: > > > > > Now, it appears, at least to me, that the world pretty much accepted > > > that the first-parent worldview is often very convenient and worth > > > supporting by the tool, so the next logical step might be to set > > > opts->mainline to 1 by default (and allow an explicit "-m $n" from > > > the command line to override it). But that should happen after this > > > patch lands---it is logically a separate step, I would think. > > > > ... and as that patch already landed... > > This worries me that it'll lead to bad surprises. Indeed. Merge commits simply do not have the same semantics as regular commits. They not only have more than one parent, they also have the further complication that they, unlike regular commits, do not introduce regular code changes, but need to reconcile diverging code changes instead. As such, cherry-picking a merge commit typically leads to *many, many* more merge conflicts than cherry-picking regular commits. It would appear to be a wise idea to keep that safety line in place, where users cherry-picking the wrong commit would have to tell Git that they really are sure that they want to cherry-pick a merge commit. And I know that I've been there myself, so it is not just some users you might dismiss as less than smart (which is actually not a smart thing to do, users are the essential audience of our software, and if we make it hard for users, it is not the users who failed). We cannot just "ignore away" that merge commits are different from regular commits: Neither in the data shape nor in their purpose are they the same. Ciao, Dscho
