Sergey OrganovHello,
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
Junio C HamanoRe: Rebase options via git pull
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.
Ævar Arnfjörð BjarmasonRe: 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.
Sergey OrganovRe: Rebase options via git pull
Æ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
Alex HenrieRe: Rebase options via git pull
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
Đoàn Trần Công DanhRe: Rebase options via git pull
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
Alex HenrieRe: Rebase options via git pull
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
Sergey OrganovRe: Rebase options via git pull
Đ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
Ævar Arnfjörð BjarmasonRe: Rebase options via git pull
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.
Sergey OrganovRe: Rebase options via git pull
Æ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
Đoàn Trần Công DanhRe: Rebase options via git pull
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
Sergey OrganovRe: Rebase options via git pull
Đ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
Đoàn Trần Công DanhRe: Rebase options via git pull
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