Hi Buga, On Sun, 11 Mar 2018, Igor Djordjevic 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. > 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. Sure, for someone who read the manual, that would be easy to use. Of course, that's the minority. Also: the `edit` command is poorly named to begin with. A much cleaner design would be to introduce the `break` command as suggested by Stephan. > 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)... > > [1] https://public-inbox.org/git/f3872fb9-01bc-b2f1-aee9-cfc0e4db77d6@xxxxxxxxx/ Well, the `-R` option is no worse than `git merge`'s `-s <strategy>` option (which *also* changes the strategies rather drastically). Ciao, Dscho
