{"thread":{"id":"55684","subject":"Rebase options via git pull","startedAt":"2021-05-13T13:20:11Z","lastAt":"2021-05-17T16:15:46Z","messageCount":13,"participants":["Sergey Organov","Junio C Hamano","Alex Henrie","Đoàn Trần Công Danh","Ævar Arnfjörð Bjarmason"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"424470","messageId":"87r1iakbyn.fsf@osv.gnss.ru","threadId":"55684","inReplyTo":null,"subject":"Rebase options via git pull","fromName":"Sergey Organov","fromEmail":"sorganov@gmail.com","sentAt":"2021-05-13T13:19:44Z","receivedAt":"2021-05-13T13:20:11Z","isPatch":false,"sender":{"key":"sorganov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8501568?v=4"},"body":"Hello,\n\nIs there a way to specify additional options for \"git rebase\" when it's\ninvoked via:\n\n  git pull --rebase\n\n? What if rebase is used implicitly due to \"pull.rebase\" being set\naccordingly?\n\nIn particular, I'd like to be able to:\n\n  git pull --rebase --no-fork-point\n\nbut it doesn't work.\n\nFrom documentation is looks like \"git pull --rebase\" is still a\nsecond-class citizen. There is whole section about merge options in the\nmanual, and none about rebase options.\n\nThanks,\n-- Sergey Organov\n"},{"id":"424505","messageId":"xmqq1raabd5d.fsf@gitster.g","threadId":"55684","inReplyTo":"87r1iakbyn.fsf@osv.gnss.ru","subject":"Re: Rebase options via git pull","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-05-13T20:18:54Z","receivedAt":"2021-05-13T20:18:58Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Sergey Organov <sorganov@gmail.com> writes:\n\n> Is there a way to specify additional options for \"git rebase\" when it's\n> invoked via:\n>\n>   git pull --rebase\n>\n> ? What if rebase is used implicitly due to \"pull.rebase\" being set\n> accordingly?\n>\n> In particular, I'd like to be able to:\n>\n>   git pull --rebase --no-fork-point\n>\n> but it doesn't work.\n>\n> From documentation is looks like \"git pull --rebase\" is still a\n> second-class citizen. There is whole section about merge options in the\n> manual, and none about rebase options.\n\nYeah, it does feel like so.\n\nJust like we can pass merge-strategy specific options via -X<opt>=<val>,\ne.g.\n\n    $ git pull -Xsubtree=gitk git://ozlabs.org/~paulus/gitk.git\n\nto ask the command to invoke \"git merge -Xsubtree=gitk\" after\nfetching from the remote repository, we should allow rebase specific\noptions via a similar mechanism, e.g. -Yno-fork-point=yes (or\nsomething along that line---exact syntax does not matter).\n\nBut I do not think there currently is anything like that.\n\n"},{"id":"424535","messageId":"CAMMLpeQ8_isyDtP34p+_tEK3JAasfro7dJbVrTVPZ7C4q0kT6w@mail.gmail.com","threadId":"55684","inReplyTo":"87r1iakbyn.fsf@osv.gnss.ru","subject":"Re: Rebase options via git pull","fromName":"Alex Henrie","fromEmail":"alexhenrie24@gmail.com","sentAt":"2021-05-14T00:49:03Z","receivedAt":"2021-05-14T00:49:18Z","isPatch":false,"sender":{"key":"alexhenrie24@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5951993?v=4"},"body":"On Thu, May 13, 2021 at 7:23 AM Sergey Organov <sorganov@gmail.com> wrote:\n>\n> Hello,\n>\n> Is there a way to specify additional options for \"git rebase\" when it's\n> invoked via:\n>\n>   git pull --rebase\n>\n> ? What if rebase is used implicitly due to \"pull.rebase\" being set\n> accordingly?\n>\n> In particular, I'd like to be able to:\n>\n>   git pull --rebase --no-fork-point\n>\n> but it doesn't work.\n\nIt would be cumbersome, but you could run `git config rebase.forkPoint\nfalse` before pulling and `git config rebase.forkPoint true` after.\n\n-Alex\n"},{"id":"424536","messageId":"YJ3LJ++lsAuSkCUJ@danh.dev","threadId":"55684","inReplyTo":"CAMMLpeQ8_isyDtP34p+_tEK3JAasfro7dJbVrTVPZ7C4q0kT6w@mail.gmail.com","subject":"Re: Rebase options via git pull","fromName":"Đoàn Trần Công Danh","fromEmail":"congdanhqx@gmail.com","sentAt":"2021-05-14T00:58:15Z","receivedAt":"2021-05-14T00:58:21Z","isPatch":false,"sender":{"key":"congdanhqx@gmail.com","avatar":"https://avatars.githubusercontent.com/u/42673067?v=4"},"body":"On 2021-05-13 18:49:03-0600, Alex Henrie <alexhenrie24@gmail.com> wrote:\n> On Thu, May 13, 2021 at 7:23 AM Sergey Organov <sorganov@gmail.com> wrote:\n> >\n> > Hello,\n> >\n> > Is there a way to specify additional options for \"git rebase\" when it's\n> > invoked via:\n> >\n> >   git pull --rebase\n> >\n> > ? What if rebase is used implicitly due to \"pull.rebase\" being set\n> > accordingly?\n> >\n> > In particular, I'd like to be able to:\n> >\n> >   git pull --rebase --no-fork-point\n> >\n> > but it doesn't work.\n> \n> It would be cumbersome, but you could run `git config rebase.forkPoint\n> false` before pulling and `git config rebase.forkPoint true` after.\n\nOr, for this *specific* case:\n\n\tgit -c rebase.forkpoint=false pull --rebase\n\n-- \nDanh\n"},{"id":"424537","messageId":"CAMMLpeSaJ-tr64qMATJOodBa=jtSvN0+AdDWpGxPG09XwSfvEA@mail.gmail.com","threadId":"55684","inReplyTo":"YJ3LJ++lsAuSkCUJ@danh.dev","subject":"Re: Rebase options via git pull","fromName":"Alex Henrie","fromEmail":"alexhenrie24@gmail.com","sentAt":"2021-05-14T01:01:07Z","receivedAt":"2021-05-14T01:01:22Z","isPatch":false,"sender":{"key":"alexhenrie24@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5951993?v=4"},"body":"On Thu, May 13, 2021 at 6:58 PM Đoàn Trần Công Danh\n<congdanhqx@gmail.com> wrote:\n>\n> On 2021-05-13 18:49:03-0600, Alex Henrie <alexhenrie24@gmail.com> wrote:\n> > On Thu, May 13, 2021 at 7:23 AM Sergey Organov <sorganov@gmail.com> wrote:\n> > >\n> > > Hello,\n> > >\n> > > Is there a way to specify additional options for \"git rebase\" when it's\n> > > invoked via:\n> > >\n> > >   git pull --rebase\n> > >\n> > > ? What if rebase is used implicitly due to \"pull.rebase\" being set\n> > > accordingly?\n> > >\n> > > In particular, I'd like to be able to:\n> > >\n> > >   git pull --rebase --no-fork-point\n> > >\n> > > but it doesn't work.\n> >\n> > It would be cumbersome, but you could run `git config rebase.forkPoint\n> > false` before pulling and `git config rebase.forkPoint true` after.\n>\n> Or, for this *specific* case:\n>\n>         git -c rebase.forkpoint=false pull --rebase\n\nI forgot that you can do that. Thanks for the better answer!\n\n-Alex\n"},{"id":"424545","messageId":"875yzlu8gt.fsf@osv.gnss.ru","threadId":"55684","inReplyTo":"YJ3LJ++lsAuSkCUJ@danh.dev","subject":"Re: Rebase options via git pull","fromName":"Sergey Organov","fromEmail":"sorganov@gmail.com","sentAt":"2021-05-14T06:37:22Z","receivedAt":"2021-05-14T06:37:31Z","isPatch":false,"sender":{"key":"sorganov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8501568?v=4"},"body":"Đoàn Trần Công Danh <congdanhqx@gmail.com> writes:\n\n> On 2021-05-13 18:49:03-0600, Alex Henrie <alexhenrie24@gmail.com> wrote:\n>> On Thu, May 13, 2021 at 7:23 AM Sergey Organov <sorganov@gmail.com> wrote:\n>> >\n>> > Hello,\n>> >\n>> > Is there a way to specify additional options for \"git rebase\" when it's\n>> > invoked via:\n>> >\n>> >   git pull --rebase\n>> >\n>> > ? What if rebase is used implicitly due to \"pull.rebase\" being set\n>> > accordingly?\n>> >\n>> > In particular, I'd like to be able to:\n>> >\n>> >   git pull --rebase --no-fork-point\n>> >\n>> > but it doesn't work.\n>> \n>> It would be cumbersome, but you could run `git config rebase.forkPoint\n>> false` before pulling and `git config rebase.forkPoint true` after.\n>\n> Or, for this *specific* case:\n>\n> \tgit -c rebase.forkpoint=false pull --rebase\n\nThat's nice, thanks! Doesn't solve entire issue, but definitely better\nthan nothing.\n\nProbably add generic cmd.<cmd>.opts config support, so that I can say:\n\n  git -c cmd.rebase.opts=\"--no-fork-point --empty=keep\" pull --rebase\n\nThoughts?\n\nThanks,\n-- Sergey Organov\n"},{"id":"424556","messageId":"8735upsmg9.fsf@evledraar.gmail.com","threadId":"55684","inReplyTo":"xmqq1raabd5d.fsf@gitster.g","subject":"Re: Rebase options via git pull","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2021-05-14T09:14:53Z","receivedAt":"2021-05-14T09:18:18Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Fri, May 14 2021, Junio C Hamano wrote:\n\n> Sergey Organov <sorganov@gmail.com> writes:\n>\n>> Is there a way to specify additional options for \"git rebase\" when it's\n>> invoked via:\n>>\n>>   git pull --rebase\n>>\n>> ? What if rebase is used implicitly due to \"pull.rebase\" being set\n>> accordingly?\n>>\n>> In particular, I'd like to be able to:\n>>\n>>   git pull --rebase --no-fork-point\n>>\n>> but it doesn't work.\n>>\n>> From documentation is looks like \"git pull --rebase\" is still a\n>> second-class citizen. There is whole section about merge options in the\n>> manual, and none about rebase options.\n>\n> Yeah, it does feel like so.\n>\n> Just like we can pass merge-strategy specific options via -X<opt>=<val>,\n> e.g.\n>\n>     $ git pull -Xsubtree=gitk git://ozlabs.org/~paulus/gitk.git\n>\n> to ask the command to invoke \"git merge -Xsubtree=gitk\" after\n> fetching from the remote repository, we should allow rebase specific\n> options via a similar mechanism, e.g. -Yno-fork-point=yes (or\n> something along that line---exact syntax does not matter).\n>\n> But I do not think there currently is anything like that.\n\nIt seems much cleaner to do a bit of refactoring of their respective\nparse options specs to have \"pull\" understand the relevant subset of\nrebase or merge options depending on its mode, we do something similar\nin \"rebase\" depending on the \"rebase stage\" you're in.\n\nThat has the added benefit over your suggestion of us catching any error\nin the passed option right away, as opposed to finding you typo'd\n-Xno-spork-point when we get to running \"rebase\".\n\nWe also probably want to lib-ify the rebase logic enough that \"pull\" can\nrun it directly without spawning another process eventually, at that\npoint borrowing this \"pass arg as-is to the driver program\" syntax would\nbecome even weirder.\n"},{"id":"424631","messageId":"87r1i8fnsw.fsf@osv.gnss.ru","threadId":"55684","inReplyTo":"8735upsmg9.fsf@evledraar.gmail.com","subject":"Re: Rebase options via git pull","fromName":"Sergey Organov","fromEmail":"sorganov@gmail.com","sentAt":"2021-05-15T07:39:43Z","receivedAt":"2021-05-15T07:39:49Z","isPatch":false,"sender":{"key":"sorganov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8501568?v=4"},"body":"Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:\n\n> On Fri, May 14 2021, Junio C Hamano wrote:\n>\n>> Sergey Organov <sorganov@gmail.com> writes:\n>>\n>>> Is there a way to specify additional options for \"git rebase\" when it's\n>>> invoked via:\n>>>\n>>>   git pull --rebase\n>>>\n>>> ? What if rebase is used implicitly due to \"pull.rebase\" being set\n>>> accordingly?\n>>>\n>>> In particular, I'd like to be able to:\n>>>\n>>>   git pull --rebase --no-fork-point\n>>>\n>>> but it doesn't work.\n>>>\n>>> From documentation is looks like \"git pull --rebase\" is still a\n>>> second-class citizen. There is whole section about merge options in the\n>>> manual, and none about rebase options.\n>>\n>> Yeah, it does feel like so.\n>>\n>> Just like we can pass merge-strategy specific options via -X<opt>=<val>,\n>> e.g.\n>>\n>>     $ git pull -Xsubtree=gitk git://ozlabs.org/~paulus/gitk.git\n>>\n>> to ask the command to invoke \"git merge -Xsubtree=gitk\" after\n>> fetching from the remote repository, we should allow rebase specific\n>> options via a similar mechanism, e.g. -Yno-fork-point=yes (or\n>> something along that line---exact syntax does not matter).\n>>\n>> But I do not think there currently is anything like that.\n>\n> It seems much cleaner to do a bit of refactoring of their respective\n> parse options specs to have \"pull\" understand the relevant subset of\n> rebase or merge options depending on its mode, we do something similar\n> in \"rebase\" depending on the \"rebase stage\" you're in.\n>\n> That has the added benefit over your suggestion of us catching any error\n> in the passed option right away, as opposed to finding you typo'd\n> -Xno-spork-point when we get to running \"rebase\".\n>\n> We also probably want to lib-ify the rebase logic enough that \"pull\" can\n> run it directly without spawning another process eventually, at that\n> point borrowing this \"pass arg as-is to the driver program\" syntax would\n> become even weirder.\n\nThis sounds much better indeed!\n\nTo add to the issue, there has always been confusion that in case of\nconflicts one should either do:\n\n   git merge --continue\n\nor:\n\n  git rebase --continue\n\ndepending on current configuration. So\n\n  git pull --continue\n\nwould be much appreciated, I think.\n\nThanks,\nSergey Organov\n"},{"id":"424720","messageId":"87zgwtr7i4.fsf@evledraar.gmail.com","threadId":"55684","inReplyTo":"875yzlu8gt.fsf@osv.gnss.ru","subject":"Re: Rebase options via git pull","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2021-05-17T10:11:39Z","receivedAt":"2021-05-17T10:15:37Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Fri, May 14 2021, Sergey Organov wrote:\n\n> Đoàn Trần Công Danh <congdanhqx@gmail.com> writes:\n>\n>> On 2021-05-13 18:49:03-0600, Alex Henrie <alexhenrie24@gmail.com> wrote:\n>>> On Thu, May 13, 2021 at 7:23 AM Sergey Organov <sorganov@gmail.com> wrote:\n>>> >\n>>> > Hello,\n>>> >\n>>> > Is there a way to specify additional options for \"git rebase\" when it's\n>>> > invoked via:\n>>> >\n>>> >   git pull --rebase\n>>> >\n>>> > ? What if rebase is used implicitly due to \"pull.rebase\" being set\n>>> > accordingly?\n>>> >\n>>> > In particular, I'd like to be able to:\n>>> >\n>>> >   git pull --rebase --no-fork-point\n>>> >\n>>> > but it doesn't work.\n>>> \n>>> It would be cumbersome, but you could run `git config rebase.forkPoint\n>>> false` before pulling and `git config rebase.forkPoint true` after.\n>>\n>> Or, for this *specific* case:\n>>\n>> \tgit -c rebase.forkpoint=false pull --rebase\n>\n> That's nice, thanks! Doesn't solve entire issue, but definitely better\n> than nothing.\n>\n> Probably add generic cmd.<cmd>.opts config support, so that I can say:\n>\n>   git -c cmd.rebase.opts=\"--no-fork-point --empty=keep\" pull --rebase\n>\n> Thoughts?\n\nIt's been discussed before (but I did not dig up the discussions,\nsorry). It's been considered a bad idea, because our commands are a\nmixture of plumbing/porcelain commands and switches, so we want to be\nable to reliably invoke say ls-tree with some switches internally,\nwithout config tripping us up.\n\nOf course we could make this sort of thing work by selectively ignoring\nthe config, but such a thing would be equal in complexity to the effort\nof assering that it's safe to introduce new rebase.* config in the\ncodebase for every switch it has now, but with a less friendly interface\nboth for git itself and users.\n\nI.e. instead of rebase.noForkPoint=<bool> we'd need to to getopt parsing\non some cmd.rebase.opts string.\n\nI don't see why in this case what I suggested elsewhere in the thread\nwouldn't be viable, i.e. you specify --rebase or --merge to \"pull\", and\nthat affects how we interpret the rest of the options. I haven't tried\nit though, so there may be hidden gotchas there I haven't thought of.\n"},{"id":"424733","messageId":"87k0nxv8tt.fsf@osv.gnss.ru","threadId":"55684","inReplyTo":"87zgwtr7i4.fsf@evledraar.gmail.com","subject":"Re: Rebase options via git pull","fromName":"Sergey Organov","fromEmail":"sorganov@gmail.com","sentAt":"2021-05-17T12:33:18Z","receivedAt":"2021-05-17T12:33:29Z","isPatch":false,"sender":{"key":"sorganov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8501568?v=4"},"body":"Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:\n\n> On Fri, May 14 2021, Sergey Organov wrote:\n>\n>> Đoàn Trần Công Danh <congdanhqx@gmail.com> writes:\n>>\n>>> On 2021-05-13 18:49:03-0600, Alex Henrie <alexhenrie24@gmail.com> wrote:\n>>>> On Thu, May 13, 2021 at 7:23 AM Sergey Organov <sorganov@gmail.com> wrote:\n>>>> >\n>>>> > Hello,\n>>>> >\n>>>> > Is there a way to specify additional options for \"git rebase\" when it's\n>>>> > invoked via:\n>>>> >\n>>>> >   git pull --rebase\n>>>> >\n>>>> > ? What if rebase is used implicitly due to \"pull.rebase\" being set\n>>>> > accordingly?\n>>>> >\n>>>> > In particular, I'd like to be able to:\n>>>> >\n>>>> >   git pull --rebase --no-fork-point\n>>>> >\n>>>> > but it doesn't work.\n>>>> \n>>>> It would be cumbersome, but you could run `git config rebase.forkPoint\n>>>> false` before pulling and `git config rebase.forkPoint true` after.\n>>>\n>>> Or, for this *specific* case:\n>>>\n>>> \tgit -c rebase.forkpoint=false pull --rebase\n>>\n>> That's nice, thanks! Doesn't solve entire issue, but definitely better\n>> than nothing.\n>>\n>> Probably add generic cmd.<cmd>.opts config support, so that I can say:\n>>\n>>   git -c cmd.rebase.opts=\"--no-fork-point --empty=keep\" pull --rebase\n>>\n>> Thoughts?\n>\n> It's been discussed before (but I did not dig up the discussions,\n> sorry). It's been considered a bad idea, because our commands are a\n> mixture of plumbing/porcelain commands and switches, so we want to be\n> able to reliably invoke say ls-tree with some switches internally,\n> without config tripping us up.\n>\n> Of course we could make this sort of thing work by selectively ignoring\n> the config, but such a thing would be equal in complexity to the effort\n> of assering that it's safe to introduce new rebase.* config in the\n> codebase for every switch it has now, but with a less friendly interface\n> both for git itself and users.\n\nI don't see much complexity here. We'd then just need to effectively\ninvoke ls-tree internally like this:\n\n   git -c 'cmd.ls-tree.opts=' ls-tree\n\nNot a big deal.\n\n>\n> I.e. instead of rebase.noForkPoint=<bool> we'd need to to getopt parsing\n> on some cmd.rebase.opts string.\n\nAs this is meant to be generic, then yes, every command will first parse\ncorresponding config option, then command-line options, rebase not being\nany different.\n\n>\n> I don't see why in this case what I suggested elsewhere in the thread\n> wouldn't be viable, i.e. you specify --rebase or --merge to \"pull\", and\n> that affects how we interpret the rest of the options. I haven't tried\n> it though, so there may be hidden gotchas there I haven't thought of.\n\nThis is the best solution for \"git pull\" indeed, but the above is a\ngeneric feature that could provide solution in cases like this, where\nimmediate specific solution is not (yet) available.\n\nThanks,\n-- Sergey Organov\n"},{"id":"424734","messageId":"YKJkmws18M6oJZXy@danh.dev","threadId":"55684","inReplyTo":"87k0nxv8tt.fsf@osv.gnss.ru","subject":"Re: Rebase options via git pull","fromName":"Đoàn Trần Công Danh","fromEmail":"congdanhqx@gmail.com","sentAt":"2021-05-17T12:42:03Z","receivedAt":"2021-05-17T12:42:11Z","isPatch":false,"sender":{"key":"congdanhqx@gmail.com","avatar":"https://avatars.githubusercontent.com/u/42673067?v=4"},"body":"On 2021-05-17 15:33:18+0300, Sergey Organov <sorganov@gmail.com> wrote:\n> >> Probably add generic cmd.<cmd>.opts config support, so that I can say:\n> >>\n> >>   git -c cmd.rebase.opts=\"--no-fork-point --empty=keep\" pull --rebase\n> >>\n> >> Thoughts?\n> >\n> > It's been discussed before (but I did not dig up the discussions,\n> > sorry). It's been considered a bad idea, because our commands are a\n> > mixture of plumbing/porcelain commands and switches, so we want to be\n> > able to reliably invoke say ls-tree with some switches internally,\n> > without config tripping us up.\n> >\n> > Of course we could make this sort of thing work by selectively ignoring\n> > the config, but such a thing would be equal in complexity to the effort\n> > of assering that it's safe to introduce new rebase.* config in the\n> > codebase for every switch it has now, but with a less friendly interface\n> > both for git itself and users.\n> \n> I don't see much complexity here. We'd then just need to effectively\n> invoke ls-tree internally like this:\n> \n>    git -c 'cmd.ls-tree.opts=' ls-tree\n> \n> Not a big deal.\n\nIt's a big deal.\n\nScripts was written with plumbing command and expect stable output.\nIf such change can be accepted, a lot of scripts will begin to fail.\n\n> > I.e. instead of rebase.noForkPoint=<bool> we'd need to to getopt parsing\n> > on some cmd.rebase.opts string.\n> \n> As this is meant to be generic, then yes, every command will first parse\n> corresponding config option, then command-line options, rebase not being\n> any different.\n> \n> >\n> > I don't see why in this case what I suggested elsewhere in the thread\n> > wouldn't be viable, i.e. you specify --rebase or --merge to \"pull\", and\n> > that affects how we interpret the rest of the options. I haven't tried\n> > it though, so there may be hidden gotchas there I haven't thought of.\n\nI didn't follow that sub-thread. However, I think we can extend\ngit-pull with a dedicated option prefix for options that would be\npassed down to git-merge or git-rebase.\nSililar to -W of CCLD (as in gcc -W,--as-needed)\n\n-- \nDanh\n"},{"id":"424736","messageId":"87a6otv7lm.fsf@osv.gnss.ru","threadId":"55684","inReplyTo":"YKJkmws18M6oJZXy@danh.dev","subject":"Re: Rebase options via git pull","fromName":"Sergey Organov","fromEmail":"sorganov@gmail.com","sentAt":"2021-05-17T12:59:49Z","receivedAt":"2021-05-17T12:59:54Z","isPatch":false,"sender":{"key":"sorganov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8501568?v=4"},"body":"Đoàn Trần Công Danh <congdanhqx@gmail.com> writes:\n\n> On 2021-05-17 15:33:18+0300, Sergey Organov <sorganov@gmail.com> wrote:\n>> >> Probably add generic cmd.<cmd>.opts config support, so that I can say:\n>> >>\n>> >>   git -c cmd.rebase.opts=\"--no-fork-point --empty=keep\" pull --rebase\n>> >>\n>> >> Thoughts?\n>> >\n>> > It's been discussed before (but I did not dig up the discussions,\n>> > sorry). It's been considered a bad idea, because our commands are a\n>> > mixture of plumbing/porcelain commands and switches, so we want to be\n>> > able to reliably invoke say ls-tree with some switches internally,\n>> > without config tripping us up.\n>> >\n>> > Of course we could make this sort of thing work by selectively ignoring\n>> > the config, but such a thing would be equal in complexity to the effort\n>> > of assering that it's safe to introduce new rebase.* config in the\n>> > codebase for every switch it has now, but with a less friendly interface\n>> > both for git itself and users.\n>> \n>> I don't see much complexity here. We'd then just need to effectively\n>> invoke ls-tree internally like this:\n>> \n>>    git -c 'cmd.ls-tree.opts=' ls-tree\n>> \n>> Not a big deal.\n>\n> It's a big deal.\n>\n> Scripts was written with plumbing command and expect stable output.\n> If such change can be accepted, a lot of scripts will begin to fail.\n\nMakes sense. Then simply don't do it for plumbing?\n\nThanks,\n-- Sergey Organov\n"},{"id":"424748","messageId":"YKKCQmaEHMR5WATP@danh.dev","threadId":"55684","inReplyTo":"87a6otv7lm.fsf@osv.gnss.ru","subject":"Re: Rebase options via git pull","fromName":"Đoàn Trần Công Danh","fromEmail":"congdanhqx@gmail.com","sentAt":"2021-05-17T14:48:34Z","receivedAt":"2021-05-17T16:15:46Z","isPatch":false,"sender":{"key":"congdanhqx@gmail.com","avatar":"https://avatars.githubusercontent.com/u/42673067?v=4"},"body":"On 2021-05-17 15:59:49+0300, Sergey Organov <sorganov@gmail.com> wrote:\n> Đoàn Trần Công Danh <congdanhqx@gmail.com> writes:\n> \n>> On 2021-05-17 15:33:18+0300, Sergey Organov <sorganov@gmail.com> wrote:\n>>> >> Probably add generic cmd.<cmd>.opts config support, so that I can say:\n>>> >>\n>>> >>   git -c cmd.rebase.opts=\"--no-fork-point --empty=keep\" pull --rebase\n>>> >>\n>>> >> Thoughts?\n>>> >\n>>> > It's been discussed before (but I did not dig up the discussions,\n>>> > sorry). It's been considered a bad idea, because our commands are a\n>>> > mixture of plumbing/porcelain commands and switches, so we want to be\n>>> > able to reliably invoke say ls-tree with some switches internally,\n>>> > without config tripping us up.\n>>> >\n>>> > Of course we could make this sort of thing work by selectively ignoring\n>>> > the config, but such a thing would be equal in complexity to the effort\n>>> > of assering that it's safe to introduce new rebase.* config in the\n>>> > codebase for every switch it has now, but with a less friendly interface\n>>> > both for git itself and users.\n>>> \n>>> I don't see much complexity here. We'd then just need to effectively\n>>> invoke ls-tree internally like this:\n>>> \n>>>    git -c 'cmd.ls-tree.opts=' ls-tree\n>>> \n>>> Not a big deal.\n>>\n>> It's a big deal.\n>>\n>> Scripts was written with plumbing command and expect stable output.\n>> If such change can be accepted, a lot of scripts will begin to fail.\n> \n> Makes sense. Then simply don't do it for plumbing?\n\nThen, we will get back to the state Ævar pointed out.\n\nQuoted again:\n\n>>> > Of course we could make this sort of thing work by selectively ignoring\n>>> > the config, but such a thing would be equal in complexity to the effort\n>>> > of assering that it's safe to introduce new rebase.* config in the\n>>> > codebase for every switch it has now, but with a less friendly interface\n>>> > both for git itself and users.\n\nAnyway, it's not only plumbing command, it's also semi-plumbing\ncommands (the ones accept --porcelain option) like:\n\n\tgit status --porcelain[=<version>]\n\n-- \nDanh\n"}]}