Elijah Newren <newren@xxxxxxxxx> writes: > 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. Perhaps some folks > cherry-pick merges around intentionally, but I would want that to be a > rare occurrence at most. There are lots of folks at $DAYJOB that > cherry-pick things, not all of them are expert git-users, and I am > certain several have erroneously attempted to cherry-pick merges > before. Wow, random Joes cherry-picking here and there... Sounds like a bigger problem is lurking here. > I would much rather they continued to get an error message > and then asked other folks for help so that someone can explain to > them what they should instead be doing rather than silently changing > the current error into an unwanted operation. Granted, the users will > at least get a confusing "Merge branch <foo>" commit message for > something that isn't a merge, but I don't think the users will notice > that either. It just means we've got both confusing and ugly history > without the necessary individual commits or with too much having been > cherry-picked. To me it seems that cherry-picking wrong commit is cherry-picking wrong commit, no matter if it's a merge or not. I don't think that trying to save a user from such a mistake worth the trouble, given that cherry-pick is reversible operation, but I still see your point. > If -m 1 is too much to ask people to specify, could we provide some > other shorthand? Or at least make a default-off config option people > would have to set if they want a cherry-pick of a merge to succeed > without specifying -m? If we decide we still need this safety precaution, I'd opt to continue to require '-m 1' to cherry-pick a merge, rather than adding some special support. Not such a big deal. BTW, doesn't git have generic configuration support to add default option to a command, I wonder (I'm aware of aliases, but they don't seem to fit)? The C.J. then would simply add '-m 1' to 'cherry-pick' in configuration. No luck? -- Sergey
