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

From: Philip Oakley <philipoakley@iee.email>
Date: Jul 29, 2021, 09:58 UTC
Message-ID: <dc7668ff-37ad-1d9e-fc92-df432549b4e2@iee.email>
In-Reply-To: <CACx-yZ1Je+tnZdJ21gDPeuQa-QTuY2t9mDujNr7wqJWFMwwzxA@mail.gmail.com>

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

Show 6 quoted lines

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

Show 12 quoted lines

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

Show 26 quoted lines

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