On Fri, May 14 2021, Junio C Hamano wrote: > Sergey Organov <sorganov@xxxxxxxxx> 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.
