Hi Buga, On Tue, 13 Mar 2018, Igor Djordjevic wrote: > 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. That is only because the RFC seems to go out of its way to break down a single merge commit into as many commits as there are merge commit parents. This is a pretty convoluted way to think about it: if you have three parent commits, for example, that way of thinking would introduce three intermediate commits, one with the changes of parent 2 & 3 combined, one with the changes of parent 1 & 3 combined, and one with the changes of parent 1 & 2 combined. To rebase those commits, you essentially have to rebase *every parent's changes twice*. It gets worse with merge commits that have 4 parents. In that case, you have to rebase every parent's changes *three times*. And so on. > > 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. I really get the impression that you reject Phillip's proposal on the ground of not being yours. In other words, the purpose of this here argument is to praise one proposal because of its heritage, rather than trying to come up with the best solution. On that basis, I will go with the proposal that is clearly the simplest and does the job and gets away with avoiding unnecessary work. > > 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. His approach is showing that he wants to shoehorn the "rebase a merge commit" idea into a form where you can cherry-pick *something*. It does not have to make sense. And to me, it really does not. > 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. Except that Phillip's simplification is not a simplification. It comes from a different point of view: trying to reconcile the diverging changes. Phillip's is a true generalization of the "rebase vs merge" story: it is no longer about merging, or about rebasing, but about reconciling divergent commit histories, with whatever tool is appropriate. Ciao, Dscho
