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

Is there a reasonable way to use the two-dot range notation in git
rebase, particularly in an  --onto situation?

In my case I have a short series that depends on both some existing Git
for Windows (GfW) patches (`main` branch), and some patches now in
`git/master`. I'm now able to rebase it onto the GfW `shears/master`
branch which contains both sets of patches (and one that was in the last
git release).

It felt that it ought to be possible to use a simple two dot range to
extract my series, rather than identifying the individual end points in
a similar manner to that used in the description"set of commits .. shown
by `git log <upstream>..HEAD`".

Or is this something that could be a project?
--

Philip

Hi Philip,

    git log upstream..HEAD

gives you all commits reachable from "HEAD", but not reachable from
"upstream". If you want to rebase this range and copy it onto newbase,
you'd run

    git rebase --onto newbase upstream

This will take the commits upstream..HEAD (the HEAD argument is
implicit), and you end up with

    newbase-.....-HEAD

containing all commits from (the previous) "HEAD" up to (but
excluding) "upstream". If "newbase" and "upstream" are identical, the
command can be simplified to `git rebase newbase`.

Maybe I'm misunderstanding the problem? Can you give an example of
`git rebase --onto newbase upstream branch` not working as expected?

Regards
Daniel

On Wed, Jul 28, 2021 at 5:38 PM Philip Oakley [off-list ref] wrote:

Is there a reasonable way to use the two-dot range notation in git
rebase, particularly in an  --onto situation?

In my case I have a short series that depends on both some existing Git
for Windows (GfW) patches (`main` branch), and some patches now in
`git/master`. I'm now able to rebase it onto the GfW `shears/master`
branch which contains both sets of patches (and one that was in the last
git release).

It felt that it ought to be possible to use a simple two dot range to
extract my series, rather than identifying the individual end points in
a similar manner to that used in the description"set of commits .. shown
by `git log <upstream>..HEAD`".

Or is this something that could be a project?
--

Philip

-- 
typed with http://neo-layout.org

On 28/07/2021 17:33, Daniel Knittl-Frank wrote:

Hi Philip,

    git log upstream..HEAD

gives you all commits reachable from "HEAD", but not reachable from
"upstream". 

My comment was: why do we need this convenient explanation in the
description, yet 'disallow' it as a method of actually indicating that
very range?

Also log will list all those commits, while the command just wants the
`^start end` commits (equiv: `start..end`), even if rebase (as I'd
understand it) wouldn't want the (^)not notation.

If you want to rebase this range and copy it onto newbase,
you'd run

    git rebase --onto newbase upstream

Here `newbase` would be my 'upstream', while `upstream` is the
'oldstream' (much hilarity and confusion...). I already have an
`upstream` set for the branch, but it's not where it needs transplanting
to in this case [That's because the Git for Windows branches are moving
targets as Git itself moves beneath it and dependent patches could be
anywhere! I have a choice of about 5 'onto' locations depending on where
the precursor patches are located..] .

This will take the commits upstream..HEAD (the HEAD argument is
implicit), and you end up with

    newbase-.....-HEAD

containing all commits from (the previous) "HEAD" up to (but
excluding) "upstream". If "newbase" and "upstream" are identical, the
command can be simplified to `git rebase newbase`.

Maybe I'm misunderstanding the problem? Can you give an example of
`git rebase --onto newbase upstream branch` not working as expected?

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` ? "

In some-ways it feels the same as the current `git pull` discussion
where historical workflow practices are baked in to the otherwise
workflow-agnostic git command structure.

regards

Philip

Regards
Daniel

On Wed, Jul 28, 2021 at 5:38 PM Philip Oakley [off-list ref] wrote:

quoted

Is there a reasonable way to use the two-dot range notation in git
rebase, particularly in an  --onto situation?

In my case I have a short series that depends on both some existing Git
for Windows (GfW) patches (`main` branch), and some patches now in
`git/master`. I'm now able to rebase it onto the GfW `shears/master`
branch which contains both sets of patches (and one that was in the last
git release).

It felt that it ought to be possible to use a simple two dot range to
extract my series, rather than identifying the individual end points in
a similar manner to that used in the description"set of commits .. shown
by `git log <upstream>..HEAD`".

Or is this something that could be a project?
--

Philip

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

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

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

-Peff

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