Junio C Hamano <gitster@xxxxxxxxx> writes:
> Jeff King <peff@xxxxxxxx> writes:
>
>> 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
