Re: [PATCH RFC] rebase: add --revisions flag

Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:

As somebody mentioned, "--cherry-picking", similar to "am --rebasing" that is also an unadvertised internal implementation detail, is a good name.

In the very old days, the original "rebase" command was a command to "set-up and run 'am -3' command in order to transplant the current branch onto somewhere else."

That was obviously too long for a command name and description, and I shorten it to "rebase", to name the command after what it is _for_ (not "what it does", nor "how it does it"). Because the command was to "set up and run am-3", it was natural at the conceptual level that the way to continue after a failed/conflicted patch application was "am --resolved".

But since then, the concept of "rebasing" got established more firmly and how "rebase" can be done has become much less relevant. The original name "rebase" stopped being short for "set up and run am-3 for rebasing", but about what it _does_ (i.e. "it rebases"). And "rebase --continue" has become a natural way to drive "am --continue" at that point, to accomodate for the change in the end-user conception. These days, "set up and run am-3 for rebasing" is not even _how_ it does the "rebase", as "rebase -i" does not even use am-3. So "rebase --continue" was a logical conclusion of the command's evolution.

The lesson to be learned from this history is that "cherry-pick A..B" that internally runs "rebase --cherry-picking" will need a similar "--continue" support that delegates to "rebase". "running am", which was originally the whole point of "rebase", later became an implementation detail, and we needed to teach "--continue" to "rebase" at that point.

Because from day one "running rebase -i" will be an implementation detail of "cherry-pick A..B", we need to teach "cherry-pick" to pass "--abort", "--continue", etc. to underlying "rebase" for the same reason.