Re: Using two-dot range notation in `git rebase`?

Junio C Hamano [off-list ref] writes:

Jeff King [off-list ref] writes:

quoted

I do think "git rebase --onto here old..end" is a sensible thing to ask
for. If we were designing it today, I'd probably suggest that rebase
take arbitrary revision sets (and either require "--onto", or perhaps as
long as there is only one negative tip given, that becomes the "--onto"
point).

The unfortunate origin of "rebase" makes this a bit awkward.  If it
were a tool to cherry-pick multiple commits on top of the current
commit ("on arbitrary point" is trivially implemented by first
checking that point out and make it cuttent), the range notation
would have made a lot more sense, and I think it indeed is what the
multi-pick kind of "git cherry-pick" today does.

But "rebase" is a tool to "rebase a branch", and it is done by
replaying the history leading to the tip of a given branch (the one
that is currently checked out being the default) on top of another
commit.  So its parameters serve dual purpose---which part of the
commit DAG to take commits to be replayed from *and* which branch
will be used to point at the tip of the resulting rewritten history.

If you can forget the latter, then multi-pick cherry-pick is already
there [*1*].

To me it seems like the long-term way to go is to obsolete cherry-pick
as end-user interface in favor of something like "git rebase --pick", to
stop repeating the same functionality in both "rebase" and
"cherry-pick". Besides, the two-dot notation would fit nicely then.

"Take these commits and put them there" (= current rebase) and "take
those commits and put them here" (= current cherry-pick) are similar
enough to be handled by the same command with the same set of features.

Thanks,
-- 
Sergey Organov