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

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