Rebase options via git pull

Rebase options via git pull

[Sergey Organov]

Hello,

Is there a way to specify additional options for "git rebase" when it's
invoked via:

  git pull --rebase

? What if rebase is used implicitly due to "pull.rebase" being set
accordingly?

In particular, I'd like to be able to:

  git pull --rebase --no-fork-point

but it doesn't work.

From documentation is looks like "git pull --rebase" is still a
second-class citizen. There is whole section about merge options in the
manual, and none about rebase options.

Thanks,
-- Sergey Organov

Re: Rebase options via git pull

[Junio C Hamano]

Sergey Organov <sorganov@gmail.com> writes:

> Is there a way to specify additional options for "git rebase" when it's
> invoked via:
>
>   git pull --rebase
>
> ? What if rebase is used implicitly due to "pull.rebase" being set
> accordingly?
>
> In particular, I'd like to be able to:
>
>   git pull --rebase --no-fork-point
>
> but it doesn't work.
>
> From documentation is looks like "git pull --rebase" is still a
> second-class citizen. There is whole section about merge options in the
> manual, and none about rebase options.

Yeah, it does feel like so.

Just like we can pass merge-strategy specific options via -X<opt>=<val>,
e.g.

    $ git pull -Xsubtree=gitk git://ozlabs.org/~paulus/gitk.git

to ask the command to invoke "git merge -Xsubtree=gitk" after
fetching from the remote repository, we should allow rebase specific
options via a similar mechanism, e.g. -Yno-fork-point=yes (or
something along that line---exact syntax does not matter).

But I do not think there currently is anything like that.

Re: Rebase options via git pull

[Ævar Arnfjörð Bjarmason]

On Fri, May 14 2021, Junio C Hamano wrote:

> Sergey Organov <sorganov@gmail.com> writes:
>
>> Is there a way to specify additional options for "git rebase" when it's
>> invoked via:
>>
>>   git pull --rebase
>>
>> ? What if rebase is used implicitly due to "pull.rebase" being set
>> accordingly?
>>
>> In particular, I'd like to be able to:
>>
>>   git pull --rebase --no-fork-point
>>
>> but it doesn't work.
>>
>> From documentation is looks like "git pull --rebase" is still a
>> second-class citizen. There is whole section about merge options in the
>> manual, and none about rebase options.
>
> Yeah, it does feel like so.
>
> Just like we can pass merge-strategy specific options via -X<opt>=<val>,
> e.g.
>
>     $ git pull -Xsubtree=gitk git://ozlabs.org/~paulus/gitk.git
>
> to ask the command to invoke "git merge -Xsubtree=gitk" after
> fetching from the remote repository, we should allow rebase specific
> options via a similar mechanism, e.g. -Yno-fork-point=yes (or
> something along that line---exact syntax does not matter).
>
> But I do not think there currently is anything like that.

It seems much cleaner to do a bit of refactoring of their respective
parse options specs to have "pull" understand the relevant subset of
rebase or merge options depending on its mode, we do something similar
in "rebase" depending on the "rebase stage" you're in.

That has the added benefit over your suggestion of us catching any error
in the passed option right away, as opposed to finding you typo'd
-Xno-spork-point when we get to running "rebase".

We also probably want to lib-ify the rebase logic enough that "pull" can
run it directly without spawning another process eventually, at that
point borrowing this "pass arg as-is to the driver program" syntax would
become even weirder.

Re: Rebase options via git pull

[Sergey Organov]

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

> On Fri, May 14 2021, Junio C Hamano wrote:
>
>> Sergey Organov <sorganov@gmail.com> writes:
>>
>>> Is there a way to specify additional options for "git rebase" when it's
>>> invoked via:
>>>
>>>   git pull --rebase
>>>
>>> ? What if rebase is used implicitly due to "pull.rebase" being set
>>> accordingly?
>>>
>>> In particular, I'd like to be able to:
>>>
>>>   git pull --rebase --no-fork-point
>>>
>>> but it doesn't work.
>>>
>>> From documentation is looks like "git pull --rebase" is still a
>>> second-class citizen. There is whole section about merge options in the
>>> manual, and none about rebase options.
>>
>> Yeah, it does feel like so.
>>
>> Just like we can pass merge-strategy specific options via -X<opt>=<val>,
>> e.g.
>>
>>     $ git pull -Xsubtree=gitk git://ozlabs.org/~paulus/gitk.git
>>
>> to ask the command to invoke "git merge -Xsubtree=gitk" after
>> fetching from the remote repository, we should allow rebase specific
>> options via a similar mechanism, e.g. -Yno-fork-point=yes (or
>> something along that line---exact syntax does not matter).
>>
>> But I do not think there currently is anything like that.
>
> It seems much cleaner to do a bit of refactoring of their respective
> parse options specs to have "pull" understand the relevant subset of
> rebase or merge options depending on its mode, we do something similar
> in "rebase" depending on the "rebase stage" you're in.
>
> That has the added benefit over your suggestion of us catching any error
> in the passed option right away, as opposed to finding you typo'd
> -Xno-spork-point when we get to running "rebase".
>
> We also probably want to lib-ify the rebase logic enough that "pull" can
> run it directly without spawning another process eventually, at that
> point borrowing this "pass arg as-is to the driver program" syntax would
> become even weirder.

This sounds much better indeed!

To add to the issue, there has always been confusion that in case of
conflicts one should either do:

   git merge --continue

or:

  git rebase --continue

depending on current configuration. So

  git pull --continue

would be much appreciated, I think.

Thanks,
Sergey Organov

Re: Rebase options via git pull

[Alex Henrie]

On Thu, May 13, 2021 at 7:23 AM Sergey Organov <sorganov@gmail.com> wrote:
>
> Hello,
>
> Is there a way to specify additional options for "git rebase" when it's
> invoked via:
>
>   git pull --rebase
>
> ? What if rebase is used implicitly due to "pull.rebase" being set
> accordingly?
>
> In particular, I'd like to be able to:
>
>   git pull --rebase --no-fork-point
>
> but it doesn't work.

It would be cumbersome, but you could run `git config rebase.forkPoint
false` before pulling and `git config rebase.forkPoint true` after.

-Alex

Re: Rebase options via git pull

[Đoàn Trần Công Danh]

On 2021-05-13 18:49:03-0600, Alex Henrie <alexhenrie24@gmail.com> wrote:
> On Thu, May 13, 2021 at 7:23 AM Sergey Organov <sorganov@gmail.com> wrote:
> >
> > Hello,
> >
> > Is there a way to specify additional options for "git rebase" when it's
> > invoked via:
> >
> >   git pull --rebase
> >
> > ? What if rebase is used implicitly due to "pull.rebase" being set
> > accordingly?
> >
> > In particular, I'd like to be able to:
> >
> >   git pull --rebase --no-fork-point
> >
> > but it doesn't work.
> 
> It would be cumbersome, but you could run `git config rebase.forkPoint
> false` before pulling and `git config rebase.forkPoint true` after.

Or, for this *specific* case:

	git -c rebase.forkpoint=false pull --rebase

-- 
Danh

Re: Rebase options via git pull

[Alex Henrie]

On Thu, May 13, 2021 at 6:58 PM Đoàn Trần Công Danh
<congdanhqx@gmail.com> wrote:
>
> On 2021-05-13 18:49:03-0600, Alex Henrie <alexhenrie24@gmail.com> wrote:
> > On Thu, May 13, 2021 at 7:23 AM Sergey Organov <sorganov@gmail.com> wrote:
> > >
> > > Hello,
> > >
> > > Is there a way to specify additional options for "git rebase" when it's
> > > invoked via:
> > >
> > >   git pull --rebase
> > >
> > > ? What if rebase is used implicitly due to "pull.rebase" being set
> > > accordingly?
> > >
> > > In particular, I'd like to be able to:
> > >
> > >   git pull --rebase --no-fork-point
> > >
> > > but it doesn't work.
> >
> > It would be cumbersome, but you could run `git config rebase.forkPoint
> > false` before pulling and `git config rebase.forkPoint true` after.
>
> Or, for this *specific* case:
>
>         git -c rebase.forkpoint=false pull --rebase

I forgot that you can do that. Thanks for the better answer!

-Alex

Re: Rebase options via git pull

[Sergey Organov]

Đoàn Trần Công Danh <congdanhqx@gmail.com> writes:

> On 2021-05-13 18:49:03-0600, Alex Henrie <alexhenrie24@gmail.com> wrote:
>> On Thu, May 13, 2021 at 7:23 AM Sergey Organov <sorganov@gmail.com> wrote:
>> >
>> > Hello,
>> >
>> > Is there a way to specify additional options for "git rebase" when it's
>> > invoked via:
>> >
>> >   git pull --rebase
>> >
>> > ? What if rebase is used implicitly due to "pull.rebase" being set
>> > accordingly?
>> >
>> > In particular, I'd like to be able to:
>> >
>> >   git pull --rebase --no-fork-point
>> >
>> > but it doesn't work.
>> 
>> It would be cumbersome, but you could run `git config rebase.forkPoint
>> false` before pulling and `git config rebase.forkPoint true` after.
>
> Or, for this *specific* case:
>
> 	git -c rebase.forkpoint=false pull --rebase

That's nice, thanks! Doesn't solve entire issue, but definitely better
than nothing.

Probably add generic cmd.<cmd>.opts config support, so that I can say:

  git -c cmd.rebase.opts="--no-fork-point --empty=keep" pull --rebase

Thoughts?

Thanks,
-- Sergey Organov

Re: Rebase options via git pull

[Ævar Arnfjörð Bjarmason]

On Fri, May 14 2021, Sergey Organov wrote:

> Đoàn Trần Công Danh <congdanhqx@gmail.com> writes:
>
>> On 2021-05-13 18:49:03-0600, Alex Henrie <alexhenrie24@gmail.com> wrote:
>>> On Thu, May 13, 2021 at 7:23 AM Sergey Organov <sorganov@gmail.com> wrote:
>>> >
>>> > Hello,
>>> >
>>> > Is there a way to specify additional options for "git rebase" when it's
>>> > invoked via:
>>> >
>>> >   git pull --rebase
>>> >
>>> > ? What if rebase is used implicitly due to "pull.rebase" being set
>>> > accordingly?
>>> >
>>> > In particular, I'd like to be able to:
>>> >
>>> >   git pull --rebase --no-fork-point
>>> >
>>> > but it doesn't work.
>>> 
>>> It would be cumbersome, but you could run `git config rebase.forkPoint
>>> false` before pulling and `git config rebase.forkPoint true` after.
>>
>> Or, for this *specific* case:
>>
>> 	git -c rebase.forkpoint=false pull --rebase
>
> That's nice, thanks! Doesn't solve entire issue, but definitely better
> than nothing.
>
> Probably add generic cmd.<cmd>.opts config support, so that I can say:
>
>   git -c cmd.rebase.opts="--no-fork-point --empty=keep" pull --rebase
>
> Thoughts?

It's been discussed before (but I did not dig up the discussions,
sorry). It's been considered a bad idea, because our commands are a
mixture of plumbing/porcelain commands and switches, so we want to be
able to reliably invoke say ls-tree with some switches internally,
without config tripping us up.

Of course we could make this sort of thing work by selectively ignoring
the config, but such a thing would be equal in complexity to the effort
of assering that it's safe to introduce new rebase.* config in the
codebase for every switch it has now, but with a less friendly interface
both for git itself and users.

I.e. instead of rebase.noForkPoint=<bool> we'd need to to getopt parsing
on some cmd.rebase.opts string.

I don't see why in this case what I suggested elsewhere in the thread
wouldn't be viable, i.e. you specify --rebase or --merge to "pull", and
that affects how we interpret the rest of the options. I haven't tried
it though, so there may be hidden gotchas there I haven't thought of.

Re: Rebase options via git pull

[Sergey Organov]

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

> On Fri, May 14 2021, Sergey Organov wrote:
>
>> Đoàn Trần Công Danh <congdanhqx@gmail.com> writes:
>>
>>> On 2021-05-13 18:49:03-0600, Alex Henrie <alexhenrie24@gmail.com> wrote:
>>>> On Thu, May 13, 2021 at 7:23 AM Sergey Organov <sorganov@gmail.com> wrote:
>>>> >
>>>> > Hello,
>>>> >
>>>> > Is there a way to specify additional options for "git rebase" when it's
>>>> > invoked via:
>>>> >
>>>> >   git pull --rebase
>>>> >
>>>> > ? What if rebase is used implicitly due to "pull.rebase" being set
>>>> > accordingly?
>>>> >
>>>> > In particular, I'd like to be able to:
>>>> >
>>>> >   git pull --rebase --no-fork-point
>>>> >
>>>> > but it doesn't work.
>>>> 
>>>> It would be cumbersome, but you could run `git config rebase.forkPoint
>>>> false` before pulling and `git config rebase.forkPoint true` after.
>>>
>>> Or, for this *specific* case:
>>>
>>> 	git -c rebase.forkpoint=false pull --rebase
>>
>> That's nice, thanks! Doesn't solve entire issue, but definitely better
>> than nothing.
>>
>> Probably add generic cmd.<cmd>.opts config support, so that I can say:
>>
>>   git -c cmd.rebase.opts="--no-fork-point --empty=keep" pull --rebase
>>
>> Thoughts?
>
> It's been discussed before (but I did not dig up the discussions,
> sorry). It's been considered a bad idea, because our commands are a
> mixture of plumbing/porcelain commands and switches, so we want to be
> able to reliably invoke say ls-tree with some switches internally,
> without config tripping us up.
>
> Of course we could make this sort of thing work by selectively ignoring
> the config, but such a thing would be equal in complexity to the effort
> of assering that it's safe to introduce new rebase.* config in the
> codebase for every switch it has now, but with a less friendly interface
> both for git itself and users.

I don't see much complexity here. We'd then just need to effectively
invoke ls-tree internally like this:

   git -c 'cmd.ls-tree.opts=' ls-tree

Not a big deal.

>
> I.e. instead of rebase.noForkPoint=<bool> we'd need to to getopt parsing
> on some cmd.rebase.opts string.

As this is meant to be generic, then yes, every command will first parse
corresponding config option, then command-line options, rebase not being
any different.

>
> I don't see why in this case what I suggested elsewhere in the thread
> wouldn't be viable, i.e. you specify --rebase or --merge to "pull", and
> that affects how we interpret the rest of the options. I haven't tried
> it though, so there may be hidden gotchas there I haven't thought of.

This is the best solution for "git pull" indeed, but the above is a
generic feature that could provide solution in cases like this, where
immediate specific solution is not (yet) available.

Thanks,
-- Sergey Organov

Re: Rebase options via git pull

[Đoàn Trần Công Danh]

On 2021-05-17 15:33:18+0300, Sergey Organov <sorganov@gmail.com> wrote:
> >> Probably add generic cmd.<cmd>.opts config support, so that I can say:
> >>
> >>   git -c cmd.rebase.opts="--no-fork-point --empty=keep" pull --rebase
> >>
> >> Thoughts?
> >
> > It's been discussed before (but I did not dig up the discussions,
> > sorry). It's been considered a bad idea, because our commands are a
> > mixture of plumbing/porcelain commands and switches, so we want to be
> > able to reliably invoke say ls-tree with some switches internally,
> > without config tripping us up.
> >
> > Of course we could make this sort of thing work by selectively ignoring
> > the config, but such a thing would be equal in complexity to the effort
> > of assering that it's safe to introduce new rebase.* config in the
> > codebase for every switch it has now, but with a less friendly interface
> > both for git itself and users.
> 
> I don't see much complexity here. We'd then just need to effectively
> invoke ls-tree internally like this:
> 
>    git -c 'cmd.ls-tree.opts=' ls-tree
> 
> Not a big deal.

It's a big deal.

Scripts was written with plumbing command and expect stable output.
If such change can be accepted, a lot of scripts will begin to fail.

> > I.e. instead of rebase.noForkPoint=<bool> we'd need to to getopt parsing
> > on some cmd.rebase.opts string.
> 
> As this is meant to be generic, then yes, every command will first parse
> corresponding config option, then command-line options, rebase not being
> any different.
> 
> >
> > I don't see why in this case what I suggested elsewhere in the thread
> > wouldn't be viable, i.e. you specify --rebase or --merge to "pull", and
> > that affects how we interpret the rest of the options. I haven't tried
> > it though, so there may be hidden gotchas there I haven't thought of.

I didn't follow that sub-thread. However, I think we can extend
git-pull with a dedicated option prefix for options that would be
passed down to git-merge or git-rebase.
Sililar to -W of CCLD (as in gcc -W,--as-needed)

-- 
Danh

Re: Rebase options via git pull

[Sergey Organov]

Đoàn Trần Công Danh <congdanhqx@gmail.com> writes:

> On 2021-05-17 15:33:18+0300, Sergey Organov <sorganov@gmail.com> wrote:
>> >> Probably add generic cmd.<cmd>.opts config support, so that I can say:
>> >>
>> >>   git -c cmd.rebase.opts="--no-fork-point --empty=keep" pull --rebase
>> >>
>> >> Thoughts?
>> >
>> > It's been discussed before (but I did not dig up the discussions,
>> > sorry). It's been considered a bad idea, because our commands are a
>> > mixture of plumbing/porcelain commands and switches, so we want to be
>> > able to reliably invoke say ls-tree with some switches internally,
>> > without config tripping us up.
>> >
>> > Of course we could make this sort of thing work by selectively ignoring
>> > the config, but such a thing would be equal in complexity to the effort
>> > of assering that it's safe to introduce new rebase.* config in the
>> > codebase for every switch it has now, but with a less friendly interface
>> > both for git itself and users.
>> 
>> I don't see much complexity here. We'd then just need to effectively
>> invoke ls-tree internally like this:
>> 
>>    git -c 'cmd.ls-tree.opts=' ls-tree
>> 
>> Not a big deal.
>
> It's a big deal.
>
> Scripts was written with plumbing command and expect stable output.
> If such change can be accepted, a lot of scripts will begin to fail.

Makes sense. Then simply don't do it for plumbing?

Thanks,
-- Sergey Organov

Re: Rebase options via git pull

[Đoàn Trần Công Danh]

On 2021-05-17 15:59:49+0300, Sergey Organov <sorganov@gmail.com> wrote:
> Đoàn Trần Công Danh <congdanhqx@gmail.com> writes:
> 
>> On 2021-05-17 15:33:18+0300, Sergey Organov <sorganov@gmail.com> wrote:
>>> >> Probably add generic cmd.<cmd>.opts config support, so that I can say:
>>> >>
>>> >>   git -c cmd.rebase.opts="--no-fork-point --empty=keep" pull --rebase
>>> >>
>>> >> Thoughts?
>>> >
>>> > It's been discussed before (but I did not dig up the discussions,
>>> > sorry). It's been considered a bad idea, because our commands are a
>>> > mixture of plumbing/porcelain commands and switches, so we want to be
>>> > able to reliably invoke say ls-tree with some switches internally,
>>> > without config tripping us up.
>>> >
>>> > Of course we could make this sort of thing work by selectively ignoring
>>> > the config, but such a thing would be equal in complexity to the effort
>>> > of assering that it's safe to introduce new rebase.* config in the
>>> > codebase for every switch it has now, but with a less friendly interface
>>> > both for git itself and users.
>>> 
>>> I don't see much complexity here. We'd then just need to effectively
>>> invoke ls-tree internally like this:
>>> 
>>>    git -c 'cmd.ls-tree.opts=' ls-tree
>>> 
>>> Not a big deal.
>>
>> It's a big deal.
>>
>> Scripts was written with plumbing command and expect stable output.
>> If such change can be accepted, a lot of scripts will begin to fail.
> 
> Makes sense. Then simply don't do it for plumbing?

Then, we will get back to the state Ævar pointed out.

Quoted again:

>>> > Of course we could make this sort of thing work by selectively ignoring
>>> > the config, but such a thing would be equal in complexity to the effort
>>> > of assering that it's safe to introduce new rebase.* config in the
>>> > codebase for every switch it has now, but with a less friendly interface
>>> > both for git itself and users.

Anyway, it's not only plumbing command, it's also semi-plumbing
commands (the ones accept --porcelain option) like:

	git status --porcelain[=<version>]

-- 
Danh