Hi Buga, On Tue, 13 Mar 2018, Igor Djordjevic wrote: > On 12/03/2018 11:46, Johannes Schindelin wrote: > > > > > Sometimes one just needs to read the manual, and I don`t really > > > think this is a ton complicated, but just something we didn`t really > > > have before (real merge rebasing), so it requires a moment to grasp > > > the concept. > > > > If that were the case, we would not keep getting bug reports about > > --preserve-merges failing to reorder patches. > > Not sure where that is heading to, but what I`m arguing about is that > introducing new commands and concepts (`merge`, and with `-R`) just > makes the situation even worse (more stuff to grasp). The problem with re-using `pick` is that its concept does not apply to merges. The cherry-pick of a non-merge commit is well-defined: the current HEAD is implicitly chosen as the cherry-picked commit's (single) parent commit. There is no ambiguity here. But for merge commits, we need to specify the parent commits (apart from the first one) *explicitly*. There was no need for that in the `pick` command, nor in the concept of a cherry-pick. > Reusing existing concepts where possible doesn`t have this problem. Existing concepts are great. As long as they fit the requirements of the new scenarios. In this case, `pick` does *not* fit the requirement of "rebase a merge commit". If you really want to force the `pick` concept onto the use case where you need to "reapply" merges, then the closest you get really is Sergey's idea, which I came to reject when considering its practical implications. Even so, you would have to make the `pick` command more complicated to support merge commits. And whatever you would do to extend the `pick` command would *not make any sense* to the current use case of the `pick` command. The real problem, of course, is that a non-merge commit, when viewed from the perspective of the changes it introduced, is a very different beast than a merge commit: it does not need to reconcile changes, ever, because there is really only one "patch" to one revision. That is very different from a merge commit, whose changes can even disagree with one another (and in fact be resolved with changes disagreeing *yet again*)! > > > Saying in favor of `--rebase-merges`, you mean as a separate option, > > > alongside `--recreate-merges` (once that series lands)? > > > > No. I am against yet another option. The only reason I pollute the > > option name space further with --recreate-merges is that it would be > > confusing to users if the new mode was called --preserve-merges=v2 > > (but work *totally differently*). > > I see. So I take you`re thinking about renaming `--recreate-merges` to > `--rebase-merges` instead? Thinking about it. Nothing will happen before v2.17.0 on that front, though, because -- unlike you gentle people -- I have to focus on stabilizing Git's code base now. > That would seem sensible, too, I think, being the default usage mode in > the first place. Being able to actually (re)create merges, too, once > user goes interactive, would be "just" an additional (nice and powerful) > feature on top of it. The implementation detail is, of course, that I will introduce this with the technically-simpler strategy: always recreating merge commits with the recursive strategy. A follow-up patch series will add support for rebasing merge commits, and then use it by default. This latter part will need a lot of experimentation, though. That's why I want the --recreate-merges patch series cooking in `next` first. Ciao, Dscho
