From: Philip Oakley <philipoakley@iee.email>
To: Daniel Knittl-Frank <knittl89@googlemail.com>
Cc: Git List <git@vger.kernel.org>
Subject: Re: Using two-dot range notation in `git rebase`?
Date: Thu, 29 Jul 2021 10:58:15 +0100 [thread overview]
Message-ID: <dc7668ff-37ad-1d9e-fc92-df432549b4e2@iee.email> (raw)
In-Reply-To: <CACx-yZ1Je+tnZdJ21gDPeuQa-QTuY2t9mDujNr7wqJWFMwwzxA@mail.gmail.com>
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
>>
>>
>
next prev parent reply other threads:[~2021-07-29 9:58 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-28 15:38 Using two-dot range notation in `git rebase`? Philip Oakley
2021-07-28 16:33 ` Daniel Knittl-Frank
2021-07-29 9:58 ` Philip Oakley [this message]
2021-07-29 10:21 ` Jeff King
2021-07-29 14:11 ` Philip Oakley
2021-07-29 17:09 ` Junio C Hamano
2021-07-29 19:05 ` Sergey Organov
2021-07-29 17:13 ` Junio C Hamano
2021-07-29 17:29 ` Jeff King
2021-07-29 19:33 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=dc7668ff-37ad-1d9e-fc92-df432549b4e2@iee.email \
--to=philipoakley@iee.email \
--cc=git@vger.kernel.org \
--cc=knittl89@googlemail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).