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

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

[Philip Oakley]

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

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

[Daniel Knittl-Frank]

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 <philipoakley@iee.email> 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

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

[Philip Oakley]

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 <philipoakley@iee.email> 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
>>
>>
>

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

[Jeff King]

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

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

[Philip Oakley]

On 29/07/2021 11:21, Jeff King wrote:
> 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).

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

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

[Junio C Hamano]

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

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

[Sergey Organov]

Junio C Hamano <gitster@pobox.com> writes:

> 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*].

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

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

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> long as there is only one negative tip given, that becomes the "--onto"
> point).

So "git newbase [--options] A..B" would

 - checks if B names an existing branch or just a commit

 - detaches HEAD at commit A

 - replays commits in DAG A..B on top of it; the exact way the
   history is replayed is affected by the options given (e.g. "-m"
   and "-p" may try to preserve history shapes)

 - if B was determined to be a branch name, "git branch -f" to it;
   otherwise leave the HEAD detached.

which all sounds OK, but I do not see a huge improvement over the
current "git rebase [--options] A B" (other than that you can type
double dot instead of a single space).

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

[Jeff King]

On Thu, Jul 29, 2021 at 10:13:59AM -0700, Junio C Hamano wrote:

> Jeff King <peff@peff.net> writes:
> 
> > long as there is only one negative tip given, that becomes the "--onto"
> > point).
> 
> So "git newbase [--options] A..B" would
> 
>  - checks if B names an existing branch or just a commit
> 
>  - detaches HEAD at commit A
> 
>  - replays commits in DAG A..B on top of it; the exact way the
>    history is replayed is affected by the options given (e.g. "-m"
>    and "-p" may try to preserve history shapes)
> 
>  - if B was determined to be a branch name, "git branch -f" to it;
>    otherwise leave the HEAD detached.
> 
> which all sounds OK, but I do not see a huge improvement over the
> current "git rebase [--options] A B" (other than that you can type
> double dot instead of a single space).

Yeah, I don't see it as a huge benefit either.

Potentially it opens the door for stuff like:

  git rebase ^A B C D

but I am not sure if that is helpful or horrifying. ;)

(To be clear, I am not necessarily advocating any of this, but just
thinking aloud of possibilities. And I'm definitely not planning to work
on it myself.)

-Peff

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

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> Potentially it opens the door for stuff like:
>
>   git rebase ^A B C D
>
> but I am not sure if that is helpful or horrifying. ;)

It is the "you might be forgetting that 'rebase' is a tool to rebase
a single branch, and is not a tool to replay a history on a commit"
example.

The "multi-pick" variant of "git cherry-pick" probably has a lot
more affinity with the idea of specifying general sub-graph of
history to be replayed, expressed in the "externded SHA-1" syntax, I
would think.

Thanks.