On Wed, Mar 20, 2019 at 8:59 AM Sergey Organov <sorganov@xxxxxxxxx> wrote: > > 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. Indeed, I was the de facto release manager at $DAYJOB and I didn't know about needing `--mainline` until we happened to need it. At this point, it's just more fuel for me arguing that the merge commits are extraneous noise in our repo's history, but projects have inertia-of-git-workflow. > > > 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. > I'm with Sergey: that people would know what code is being brought in. We could specifically code it up so that 3-way merges still need an explicit `-m` to be set... > > 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? > I'm not quite sure how I'd do that; pointers? > -- Sergey >
