Re: [RFC] Rebasing merges: a jorney to the ultimate solution(RoadClear)

Hi Dscho,

On 12/03/2018 11:37, Johannes Schindelin wrote:

quoted

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.

I would disagree here, as it seems you`re going too much into 
implementation and theory here, where it shouldn`t really matter from 
the user`s point of view - the point is to rebase a commit, `pick` it 
from one place and plant it elsewhere.

Yes, some commits might have a bit different semantics then others 
(merge vs non-merge), but it should just be an implementation detail, 
in my opinion, no need to leak it in user`s face (more than necessary).

I feel that "merge" is a command that works really well in the 
mindset of (re)creating merges. But if we are "only" rebasing an 
existing merge, `pick` seems much more appropriate (to me, at least), 
and it aligns with what I`m already expecting `pick` to be doing.

Down below, if we are (re)creating the merge, or doing magic to 
somehow just port it over, should be irrelevant. So "rebase" equals 
"pick and plant" (port), not "merge".

quoted

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.

I`m not following you here - the point is these are already existing 
commands, which would still fit in just nicely, so nothing new to 
learn nor read.

Now, if we are to discuss use cases where people don`t even know what 
they`re doing, I would think that misses the point. Besides, it`s 
always easier to make more mistakes when you introduce yet more 
commands/semantics to think about/learn, and I think it can be avoided 
here, for the better.

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.

This is orthogonal to what we`re discussing. Existing commands might 
not be perfect, but that`s what we have now, so let`s be consistent, 
not putting additional burden on the user there, at least.

But for the record - I tend to agree, I often find myself wondering 
if `edit`-ed commit means `rebase` stops after applying the changes 
and _before_ making the commit itself (so we just edit and 
--continue), or _after_ it (so we edit, `commit --amend` and 
--continue).

quoted

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@gmail.com/

Well, the `-R` option is no worse than `git merge`'s `-s <strategy>`
option (which *also* changes the strategies rather drastically).

What I wrote above, -R seems unfitting for `merge`, as we are not 
really merging, but rebasing (conceptually, not implementation wise).

And it makes even less sense in the light of that previous comment 
where "rebasing a merge" shouldn`t even allow selecting a specific 
strategy, as that would imply (re)creating the merge instead.

So using `merge` for rebasing existing (merge) commit seems as rather 
misusing the concept of `merging`.

I don`t know, I`m thinking if we are looking at todo list from 
different perspectives - to you, it seems to be a sequence of 
commands to create something new (yes, from something that already 
exists, but that`s implementation detail). In that context, using 
`merge` might have sense (even if still being a very special merge).

But to me, as we already have `pick` and not `commit` to rebase 
commits, it means we are not creating but rather reusing what we have 
(being an important concept to reason about), thus `pick` would still 
fit in for picking a merge commit just nicely, and more naturally, too.

*Maybe if* `-R` would be turned into a full fledged "rebase" (or 
"rebasing") merge strategy, written as:

	merge -s rebase -C <original--merge-commit> <merge-head>

..., might be it would make more sense to me (aligned with what 
`merge` is expected to do). But even then, I might prefer having 
`pick` as a syntactic sugar over `merge -s rebase`, at least.

In the light of this, I _could_ even see `-R` as short for `-s 
rebase`, but it still seems a bit awkward and forced.

Regards, Buga