Hi Johannes, Johannes Schindelin <johannes.schinde...@gmx.de> writes:
> Hi Buga, > > On Sun, 11 Mar 2018, Igor Djordjevic 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. -- Sergey
