On 12/03/2018 13:56, Sergey Organov wrote: > > > > I agree with both of you that `pick <merge-commit>` is inflexible > > > (not to say just plain wrong), but I never thought about it like that. > > > > > > If we are to extract further mentioned explicit old:new merge > > > parameter mapping to a separate discussion point, what we`re > > > eventually left with is just replacing this: > > > > > > merge -R -C <original--merge-commit> <merge-head> > > > > > > ... with this: > > > > > > pick <original--merge-commit> <merge-head> > > > > I see where you are coming from. > > > > I also see where users will be coming from. Reading a todo list in the > > editor is as much documentation as it is a "program to execute". And I am > > afraid that reading a command without even mentioning the term "merge" > > once is pretty misleading in this setting. > > > > And even from the theoretical point of view: cherry-picking non-merge > > commits is *so much different* from "rebasing merge commits" as discussed > > here, so much so that using the same command would be even more > > misleading. > > This last statement is plain wrong when applied to the method in the > [RFC] you are replying to. Using the method in [RFC], "cherry-pick > non-merge" is nothing more or less than reduced version of generic > "cherry-pick merge", exactly as it should be. > > Or, in other words, "cherry-pick merge" is generalization of > "cherry-pick non-merge" to multiple parents.
I think Sergey does have a point here, his approach showing it. Phillip`s simplification might be further from it, though, but we`re talking implementation again - important mental model should just be "rebasing a commit" (merge or non-merge), how we`re doing it is irrelevant for the user, the point (goal) is the same.
