Re: Rebase options via git pull

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