Hi Johannes, Johannes Schindelin <johannes.schinde...@gmx.de> writes:
> 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". It does, provided you use suitable syntax. > 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. Which one, and what are the implications that are bad, I wonder? > 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. It would rather make a lot of sense. Please don't use 'merge' to pick commits, merge ones or not! > 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*)! You'd still 'pick' it though, not 'merge'. You don't merge "merge commit", it makes no sense. It only makes perfect sense when you get rid of original "merge commit" and re-merge from scratch, as you were doing till now. >> > > 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. Switching to use it by default would be backward incompatible again? Yet another option to obsolete? Sigh. -- Sergey
