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

On 29/07/2021 11:21, Jeff King wrote:

On Thu, Jul 29, 2021 at 10:58:15AM +0100, Philip Oakley wrote:

quoted

In summary, there are two aspect:
- first, being able to use a common short-form within the command, and
- second, that the documentation's description includes rather too many
tricky concepts to properly understand all the ramifications, leaving me
to think "why can't I just say `git rebase --onto here old..end` or `git
rebase --onto here start^..end` ? "

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).

Sensible.

It might be possible to migrate to such a syntax, but we'd have to be
careful of ambiguities with the current syntax. It might be possible to
infer the intended use based on the presence or absence of negative tips

My first though was to limit it to just the double-dot itself (rather
than waiting for it's conversion to using the negative ref notation),
but that may be at the wrong part of the command line decoding.

(so "git rebase foo bar" must be "foo is the upstream, and therefore
base branch", whereas "git rebase foo..bar" is a range, though the two
would do the same thing).

I think we did something similar with cherry-pick, which originally took
only a series of single commits.

I admit that I haven't thought carefully through the details, though.
There may be some gotchas in how "rebase" treats the base branch.

My main issue (beyond the nice to have) is simply decoding all of the
documentation's terminology, which starts complex, and stays pretty
complicated... It is rather easy to mess up.

Philip