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