Hi Sergey, On Tue, 27 Mar 2018, Sergey Organov wrote: > Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > > > 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. You know what `pick` would also do, provided you use suitable syntax? Pick your nose. Don't blame me for this ridiculous turn the discussion took. Of course, using the suitable syntax you can do anything. Unless there is *already* a syntax and you cannot break it for backwards-compatibility reasons, as is the case here. But I'll stop here. Even my account how there are conceptual differences between the changes in merge vs non-merge commits (the non-merge commit *introduces* changes, the merge commit *reconciles existing* changes) seems to fly by without convincing you. I use rebase every day. I use the Git garden shears every week. If you do not trust my experience with these things, nothing will convince you. You are just stuck with your pre-existing opinion. > > 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? The strategy described in RFC v2, which does too much work, forces the user to potentially address the same merge conflicts multiple times, and worst of all: risks merge conflicts with changes the user *already* dropped. > > 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! It would rather make a lot of sense. If you completely ignored everything I said about preserve-merges. If you ignored what I said about problems moving regular `pick` lines across merge commits. If you ignored all the experience I have with Git garden shears and that I tried really patiently for an impatient man to impart on you. > > 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. No, you merge "merge head". And you use "merge commit"'s commit message. *That* makes sense. Picking a merge commit? Not so. What do you merge? The original merge commit's second parent? Or a rebased version thereof? What if that commit has been `pick`ed *twice*? No, you can repeat it all you want, it still does not make sense. Now that I think of the possiblity of picking the original parents multiple times, it does not even make theoretical sense. > > 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. Oh wow. Backwards compatibility of a feature that existed only as a topic branch in `next` before being worked on more? Any other splendid ideas? And what's that about another option to obsolete? Who said that I would obsolete any newly-introduced option? I would introduce either --recreate-merges or --rebase-merges, and then just stick with it. I guess it is my turn to sigh. Ciao, Johannes
