Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes: > 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. 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
