* Re: Using two-dot range notation in `git rebase`?
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 17:13 ` Junio C Hamano
2 siblings, 0 replies; 10+ messages in thread
From: Philip Oakley @ 2021-07-29 14:11 UTC (permalink / raw)
To: Jeff King; +Cc: Daniel Knittl-Frank, Git List
On 29/07/2021 11:21, Jeff King wrote:
> On Thu, Jul 29, 2021 at 10:58:15AM +0100, Philip Oakley wrote:
>
>> 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` ? "
> 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).
Sensible.
>
> 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
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.
> (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.
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Using two-dot range notation in `git rebase`?
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
2 siblings, 1 reply; 10+ messages in thread
From: Junio C Hamano @ 2021-07-29 17:09 UTC (permalink / raw)
To: Jeff King; +Cc: Philip Oakley, Daniel Knittl-Frank, Git List
Jeff King <peff@peff.net> writes:
> 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).
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).
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Using two-dot range notation in `git rebase`?
2021-07-29 17:09 ` Junio C Hamano
@ 2021-07-29 19:05 ` Sergey Organov
0 siblings, 0 replies; 10+ messages in thread
From: Sergey Organov @ 2021-07-29 19:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Philip Oakley, Daniel Knittl-Frank, Git List
Junio C Hamano <gitster@pobox.com> writes:
> Jeff King <peff@peff.net> writes:
>
>> 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).
>
> 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*].
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,
--
Sergey Organov
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Using two-dot range notation in `git rebase`?
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 17:13 ` Junio C Hamano
2021-07-29 17:29 ` Jeff King
2 siblings, 1 reply; 10+ messages in thread
From: Junio C Hamano @ 2021-07-29 17:13 UTC (permalink / raw)
To: Jeff King; +Cc: Philip Oakley, Daniel Knittl-Frank, Git List
Jeff King <peff@peff.net> writes:
> long as there is only one negative tip given, that becomes the "--onto"
> point).
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).
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Using two-dot range notation in `git rebase`?
2021-07-29 17:13 ` Junio C Hamano
@ 2021-07-29 17:29 ` Jeff King
2021-07-29 19:33 ` Junio C Hamano
0 siblings, 1 reply; 10+ messages in thread
From: Jeff King @ 2021-07-29 17:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Philip Oakley, Daniel Knittl-Frank, Git List
On Thu, Jul 29, 2021 at 10:13:59AM -0700, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > long as there is only one negative tip given, that becomes the "--onto"
> > point).
>
> 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).
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Using two-dot range notation in `git rebase`?
2021-07-29 17:29 ` Jeff King
@ 2021-07-29 19:33 ` Junio C Hamano
0 siblings, 0 replies; 10+ messages in thread
From: Junio C Hamano @ 2021-07-29 19:33 UTC (permalink / raw)
To: Jeff King; +Cc: Philip Oakley, Daniel Knittl-Frank, Git List
Jeff King <peff@peff.net> writes:
> 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. ;)
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.
^ permalink raw reply [flat|nested] 10+ messages in thread