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

[Junio C Hamano <gitster@pobox.com>]

Jeff King <peff@peff.net> 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*].

Before revision.c API was extended to learn rev_cmdline_info, taking
an "extended SHA-1" expression (e.g. A..B~2) from the user, and
ensuring there is only one positive tip and it is given as a branch
name was simply too cumbersome and error prone.  I do not offhand
know the current rev_cmdline_info is sufficiently rich to allow us
do so.

For the simplest "git rebase [--onto newbase] oldbase..tip", I do
not think it is such a big deal to type it with .. replaced with a
single SP, so I do not necessarily agree with you that it is a
sensible thing to ask for.

[Footnote]

*1* There is an issue in multi-pick "git cherry-pick" that I cannot
    replace my daily use of "git rebase" with it.  It does not honor
    notes rewriting and I lose the notes/amlog records.  This is
    unfortunately by design (for the same reason why the "-x" option
    lost its default status from cherry-pick, the tool tries to
    dissociate the resulting commit as much from the original commit
    as possible, and carrying forward notes attached to the original
    to the rewritten goes against that spirit).