Hi Dscho, On 11/03/2018 13:00, Johannes Schindelin wrote: > > > I actually like `pick` for _rebasing_ merge commits, as `pick` is > > already used for rebasing non-merge commits, too, so it feels natural. > > Phillip is right, though: this would repeat the design mistake of > --preserve-merges. > > We must not forget that the interactive mode is the target here, and that > the syntax (as well as the generated todo list) must allow for easy > modification. The `pick <merge>` approach does not allow that, so we > cannot use it. > > The `merge -R -C <original-commit> <merge-head>` approach is a lot better: > it offers the flexibility, without sacrificing the ease when not modifying > the todo list. Eh, I`m afraid the quote you took is missing the rest of its (important) context, where I mentioned already proposed format for `pick` in that other subthread[1], including other parameters beside merge commit to pick, as that parent mapping. 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> That is what I had in mind, seeming possibly more straightforward and beautifully aligned with previously existing (and well known) `rebase` terminology. Not to say this would make it possible to use other `rebase -i` todo list commands, too, like if you want to amend/edit merge commit after it was rebased, you would write: edit <original--merge-commit> <merge-head> ..., where in case you would simply like to reword its commit message, it would be just: reword <original--merge-commit> <merge-head> Even `squash` and `fixup` could have their place in combination with a (to be rebased) merge commit, albeit in a pretty exotic rebases, thus these could probably be just disallowed - for the time being, at least. The real power would be buried in implementation, learning to rebase merge commits, so user is left with a very familiar interface, slightly adapted do accommodate a bit different nature of merge commit in comparison to an ordinary one, also to allow a bit more of interactive rebase functionality, but it would pretty much stay the same, without even a need to learn about new `merge`, `-R`, `-C`, and so on. Yes, those would have its purpose, but for real merging then (creating new merges, or recreating old ones), not necessarily for merge rebasing. With state of `merge -R -C ...` (that `-R` being the culprit), it kind of feels like we`re now trying to bolt "rebase merges" functionality onto a totally different one (recreate merges, serving a different purpose), making them both needlessly dependent on each other, further complicating user interface, making it more confusing and less tunable as per each separate functionality needs (rebase vs. recreate). I guess I`m the one to pretty much blame here, too, as I really wanted `--recreate-merges` to handle "rebase merges" better, only to later realize it might not be the best tool for the job, and that a more separate approach would be better (at least not through the same `merge` todo list command)... Regards, Buga [1] https://public-inbox.org/git/f3872fb9-01bc-b2f1-aee9-cfc0e4db77d6@xxxxxxxxx/
