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/[email protected]/
