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

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

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:

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

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.

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

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

On Thu, Jul 29, 2021 at 10:58:15AM +0100, Philip Oakley wrote:

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

On 29/07/2021 11:21, Jeff King wrote:

Sensible.

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.

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

Jeff King <peff@peff.net> writes:

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

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

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,

Jeff King <peff@peff.net> writes:

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

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

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

Jeff King <peff@peff.net> writes:

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.