{"thread":{"id":"56830","subject":"pull.rebase config option broken in 2.33.1","startedAt":"2021-11-02T14:04:55Z","lastAt":"2021-12-02T16:54:31Z","messageCount":11,"participants":["Dmitry Marakasov","Jeff King","Elijah Newren"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"440308","messageId":"YYFEE/2g3SiM04zx@hades.panopticon","threadId":"56830","inReplyTo":null,"subject":"pull.rebase config option broken in 2.33.1","fromName":"Dmitry Marakasov","fromEmail":"amdmi3@amdmi3.ru","sentAt":"2021-11-02T13:58:43Z","receivedAt":"2021-11-02T14:04:55Z","isPatch":false,"sender":{"key":"amdmi3@amdmi3.ru","avatar":"https://avatars.githubusercontent.com/u/474217?v=4"},"body":"Hi!\n\nAfter update from 2.33.0 to 2.33.1 the pull.rebase = true option\nno longer works: `git pull` no longer tries to rebase (however manual\n`git pull --rebase` works fine):\n\n% git config pull.rebase\ntrue\n% git pull\nfatal: Not possible to fast-forward, aborting.\n% git pull --rebase\nSuccessfully rebased and updated refs/heads/local-fixes.\n% git pull\nfatal: Not possible to fast-forward, aborting.\n% grep -C1 rebase .git/config\n[pull]\n\trebase = true\n[rebase]\n\tautostash = true\n\nAfter downgrade to 2.33.0:\n\n% git pull\nCurrent branch local-fixes is up to date.\n\n-- \nDmitry Marakasov   .   55B5 0596 FF1E 8D84 5F56  9510 D35A 80DD F9D2 F77D\namdmi3@amdmi3.ru  ..:     https://github.com/AMDmi3  https://amdmi3.ru\n\n"},{"id":"440311","messageId":"YYFJEASSimMhEsYz@coredump.intra.peff.net","threadId":"56830","inReplyTo":"YYFEE/2g3SiM04zx@hades.panopticon","subject":"Re: pull.rebase config option broken in 2.33.1","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2021-11-02T14:20:00Z","receivedAt":"2021-11-02T14:20:03Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Nov 02, 2021 at 04:58:43PM +0300, Dmitry Marakasov wrote:\n\n> After update from 2.33.0 to 2.33.1 the pull.rebase = true option\n> no longer works: `git pull` no longer tries to rebase (however manual\n> `git pull --rebase` works fine):\n> \n> % git config pull.rebase\n> true\n> % git pull\n> fatal: Not possible to fast-forward, aborting.\n> % git pull --rebase\n> Successfully rebased and updated refs/heads/local-fixes.\n> % git pull\n> fatal: Not possible to fast-forward, aborting.\n> % grep -C1 rebase .git/config\n> [pull]\n> \trebase = true\n> [rebase]\n> \tautostash = true\n> \n> After downgrade to 2.33.0:\n> \n> % git pull\n> Current branch local-fixes is up to date.\n\nThis looks like the same bug discussed in:\n\n  https://lore.kernel.org/git/CH2PR06MB650424B4205102AC6A48F489B1BD9@CH2PR06MB6504.namprd06.prod.outlook.com/\n\nThere's a fix in that thread. It's currently in \"next\", but didn't quite\nmake the cutoff for the upcoming v2.34.0.\n\n-Peff\n"},{"id":"442371","messageId":"YaEh+k2q+9LoLXNh@hades.panopticon","threadId":"56830","inReplyTo":"YYFJEASSimMhEsYz@coredump.intra.peff.net","subject":"Re: pull.rebase config option broken in 2.33.1","fromName":"Dmitry Marakasov","fromEmail":"amdmi3@amdmi3.ru","sentAt":"2021-11-26T18:05:46Z","receivedAt":"2021-11-26T18:32:09Z","isPatch":false,"sender":{"key":"amdmi3@amdmi3.ru","avatar":"https://avatars.githubusercontent.com/u/474217?v=4"},"body":"* Jeff King (peff@peff.net) wrote:\n\n> > After update from 2.33.0 to 2.33.1 the pull.rebase = true option\n> > no longer works: `git pull` no longer tries to rebase (however manual\n> > `git pull --rebase` works fine):\n> > \n> > % git config pull.rebase\n> > true\n> > % git pull\n> > fatal: Not possible to fast-forward, aborting.\n> > % git pull --rebase\n> > Successfully rebased and updated refs/heads/local-fixes.\n> > % git pull\n> > fatal: Not possible to fast-forward, aborting.\n> > % grep -C1 rebase .git/config\n> > [pull]\n> > \trebase = true\n> > [rebase]\n> > \tautostash = true\n> > \n> > After downgrade to 2.33.0:\n> > \n> > % git pull\n> > Current branch local-fixes is up to date.\n> \n> This looks like the same bug discussed in:\n> \n>   https://lore.kernel.org/git/CH2PR06MB650424B4205102AC6A48F489B1BD9@CH2PR06MB6504.namprd06.prod.outlook.com/\n> \n> There's a fix in that thread. It's currently in \"next\", but didn't quite\n> make the cutoff for the upcoming v2.34.0.\n\nFor the record, the problem is still present in 2.34.1\n\n-- \nDmitry Marakasov   .   55B5 0596 FF1E 8D84 5F56  9510 D35A 80DD F9D2 F77D\namdmi3@amdmi3.ru  ..:     https://github.com/AMDmi3  https://amdmi3.ru\n\n"},{"id":"442376","messageId":"YaFVVMa9cg4gpI6b@coredump.intra.peff.net","threadId":"56830","inReplyTo":"YaEh+k2q+9LoLXNh@hades.panopticon","subject":"Re: pull.rebase config option broken in 2.33.1","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2021-11-26T21:44:52Z","receivedAt":"2021-11-26T21:46:54Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Nov 26, 2021 at 09:05:46PM +0300, Dmitry Marakasov wrote:\n\n> * Jeff King (peff@peff.net) wrote:\n> \n> > > After update from 2.33.0 to 2.33.1 the pull.rebase = true option\n> > > no longer works: `git pull` no longer tries to rebase (however manual\n> > > `git pull --rebase` works fine):\n> > > \n> > > % git config pull.rebase\n> > > true\n> > > % git pull\n> > > fatal: Not possible to fast-forward, aborting.\n> > > % git pull --rebase\n> > > Successfully rebased and updated refs/heads/local-fixes.\n> > > % git pull\n> > > fatal: Not possible to fast-forward, aborting.\n> > > % grep -C1 rebase .git/config\n> > > [pull]\n> > > \trebase = true\n> > > [rebase]\n> > > \tautostash = true\n> > > \n> > > After downgrade to 2.33.0:\n> > > \n> > > % git pull\n> > > Current branch local-fixes is up to date.\n> > \n> > This looks like the same bug discussed in:\n> > \n> >   https://lore.kernel.org/git/CH2PR06MB650424B4205102AC6A48F489B1BD9@CH2PR06MB6504.namprd06.prod.outlook.com/\n> > \n> > There's a fix in that thread. It's currently in \"next\", but didn't quite\n> > make the cutoff for the upcoming v2.34.0.\n> \n> For the record, the problem is still present in 2.34.1\n\nIn the bug I linked (and what got fixed in 2.34.1), the issue is that\nwhen the local branch is ahead of the remote, we don't say \"up to date\",\nbut complain about fast-forwards.\n\nIt's hard to tell from the output above, but it looks like you have a\ncase where there are new commits both locally and on the remote? In\nwhich case a rebase would work just fine.\n\nBut why are we complaining about \"not possible to fast-forward\"? Testing\nlocally with something like:\n\n-- >8 --\ngit init repo\ncd repo\n\ncommit() {\n\techo $1 >$1\n\tgit add $1\n\tgit commit -m $1\n}\n\ngit checkout -b local\ncommit base\ncommit local\n\ngit checkout -b remote HEAD^\ncommit remote\n\ngit checkout local\ngit config pull.rebase true\ngit pull . remote\n-- >8 --\n\nshows that we do rebase. If I set:\n\n  git config pull.ff only\n\nthen we start complaining. And that behavior did change in 2.33.1, but\nI'm not sure it's wrong. We have two conflicting config options, and the\nprecedence for which one we pick switched.\n\nDo you have that option set in your config? Try:\n\n  git config --show-origin --show-scope --get-regexp 'pull\\..*'\n\n+cc Alex and Elijah from the original 3d5fc24dae (pull: abort if\n--ff-only is given and fast-forwarding is impossible, 2021-07-21) in\ncase they have further thoughts, but I _think_ this is working as\ndesigned.\n\n-Peff\n"},{"id":"442377","messageId":"YaFViM1tTTAc48ZG@coredump.intra.peff.net","threadId":"56830","inReplyTo":"YaFVVMa9cg4gpI6b@coredump.intra.peff.net","subject":"Re: pull.rebase config option broken in 2.33.1","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2021-11-26T21:45:44Z","receivedAt":"2021-11-26T21:47:46Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Nov 26, 2021 at 04:44:52PM -0500, Jeff King wrote:\n\n> +cc Alex and Elijah from the original 3d5fc24dae (pull: abort if\n> --ff-only is given and fast-forwarding is impossible, 2021-07-21) in\n> case they have further thoughts, but I _think_ this is working as\n> designed.\n\nWhoops, forgot the cc. Original message in full below.\n\n-Peff\n\n> On Fri, Nov 26, 2021 at 09:05:46PM +0300, Dmitry Marakasov wrote:\n> \n> > * Jeff King (peff@peff.net) wrote:\n> > \n> > > > After update from 2.33.0 to 2.33.1 the pull.rebase = true option\n> > > > no longer works: `git pull` no longer tries to rebase (however manual\n> > > > `git pull --rebase` works fine):\n> > > > \n> > > > % git config pull.rebase\n> > > > true\n> > > > % git pull\n> > > > fatal: Not possible to fast-forward, aborting.\n> > > > % git pull --rebase\n> > > > Successfully rebased and updated refs/heads/local-fixes.\n> > > > % git pull\n> > > > fatal: Not possible to fast-forward, aborting.\n> > > > % grep -C1 rebase .git/config\n> > > > [pull]\n> > > > \trebase = true\n> > > > [rebase]\n> > > > \tautostash = true\n> > > > \n> > > > After downgrade to 2.33.0:\n> > > > \n> > > > % git pull\n> > > > Current branch local-fixes is up to date.\n> > > \n> > > This looks like the same bug discussed in:\n> > > \n> > >   https://lore.kernel.org/git/CH2PR06MB650424B4205102AC6A48F489B1BD9@CH2PR06MB6504.namprd06.prod.outlook.com/\n> > > \n> > > There's a fix in that thread. It's currently in \"next\", but didn't quite\n> > > make the cutoff for the upcoming v2.34.0.\n> > \n> > For the record, the problem is still present in 2.34.1\n> \n> In the bug I linked (and what got fixed in 2.34.1), the issue is that\n> when the local branch is ahead of the remote, we don't say \"up to date\",\n> but complain about fast-forwards.\n> \n> It's hard to tell from the output above, but it looks like you have a\n> case where there are new commits both locally and on the remote? In\n> which case a rebase would work just fine.\n> \n> But why are we complaining about \"not possible to fast-forward\"? Testing\n> locally with something like:\n> \n> -- >8 --\n> git init repo\n> cd repo\n> \n> commit() {\n> \techo $1 >$1\n> \tgit add $1\n> \tgit commit -m $1\n> }\n> \n> git checkout -b local\n> commit base\n> commit local\n> \n> git checkout -b remote HEAD^\n> commit remote\n> \n> git checkout local\n> git config pull.rebase true\n> git pull . remote\n> -- >8 --\n> \n> shows that we do rebase. If I set:\n> \n>   git config pull.ff only\n> \n> then we start complaining. And that behavior did change in 2.33.1, but\n> I'm not sure it's wrong. We have two conflicting config options, and the\n> precedence for which one we pick switched.\n> \n> Do you have that option set in your config? Try:\n> \n>   git config --show-origin --show-scope --get-regexp 'pull\\..*'\n> \n> \n> -Peff\n"},{"id":"442391","messageId":"CABPp-BGC5DrArqWMiwwpJQgK8WucVcAxj0Ptgpi+_KRb7V7Nwg@mail.gmail.com","threadId":"56830","inReplyTo":"YaFViM1tTTAc48ZG@coredump.intra.peff.net","subject":"Re: pull.rebase config option broken in 2.33.1","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2021-11-26T22:43:44Z","receivedAt":"2021-11-26T22:47:14Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Fri, Nov 26, 2021 at 1:45 PM Jeff King <peff@peff.net> wrote:\n>\n> On Fri, Nov 26, 2021 at 04:44:52PM -0500, Jeff King wrote:\n>\n> > +cc Alex and Elijah from the original 3d5fc24dae (pull: abort if\n> > --ff-only is given and fast-forwarding is impossible, 2021-07-21) in\n> > case they have further thoughts, but I _think_ this is working as\n> > designed.\n>\n> Whoops, forgot the cc. Original message in full below.\n\nI believe this was already fixed in 2.34.1 in commit ea1954af77\n(\"pull: should be noop when already-up-to-date\", 2021-11-17).\n\n\n\n> > On Fri, Nov 26, 2021 at 09:05:46PM +0300, Dmitry Marakasov wrote:\n> >\n> > > * Jeff King (peff@peff.net) wrote:\n> > >\n> > > > > After update from 2.33.0 to 2.33.1 the pull.rebase = true option\n> > > > > no longer works: `git pull` no longer tries to rebase (however manual\n> > > > > `git pull --rebase` works fine):\n> > > > >\n> > > > > % git config pull.rebase\n> > > > > true\n> > > > > % git pull\n> > > > > fatal: Not possible to fast-forward, aborting.\n> > > > > % git pull --rebase\n> > > > > Successfully rebased and updated refs/heads/local-fixes.\n> > > > > % git pull\n> > > > > fatal: Not possible to fast-forward, aborting.\n> > > > > % grep -C1 rebase .git/config\n> > > > > [pull]\n> > > > >         rebase = true\n> > > > > [rebase]\n> > > > >         autostash = true\n> > > > >\n> > > > > After downgrade to 2.33.0:\n> > > > >\n> > > > > % git pull\n> > > > > Current branch local-fixes is up to date.\n> > > >\n> > > > This looks like the same bug discussed in:\n> > > >\n> > > >   https://lore.kernel.org/git/CH2PR06MB650424B4205102AC6A48F489B1BD9@CH2PR06MB6504.namprd06.prod.outlook.com/\n> > > >\n> > > > There's a fix in that thread. It's currently in \"next\", but didn't quite\n> > > > make the cutoff for the upcoming v2.34.0.\n> > >\n> > > For the record, the problem is still present in 2.34.1\n> >\n> > In the bug I linked (and what got fixed in 2.34.1), the issue is that\n> > when the local branch is ahead of the remote, we don't say \"up to date\",\n> > but complain about fast-forwards.\n> >\n> > It's hard to tell from the output above, but it looks like you have a\n> > case where there are new commits both locally and on the remote? In\n> > which case a rebase would work just fine.\n> >\n> > But why are we complaining about \"not possible to fast-forward\"? Testing\n> > locally with something like:\n> >\n> > -- >8 --\n> > git init repo\n> > cd repo\n> >\n> > commit() {\n> >       echo $1 >$1\n> >       git add $1\n> >       git commit -m $1\n> > }\n> >\n> > git checkout -b local\n> > commit base\n> > commit local\n> >\n> > git checkout -b remote HEAD^\n> > commit remote\n> >\n> > git checkout local\n> > git config pull.rebase true\n> > git pull . remote\n> > -- >8 --\n> >\n> > shows that we do rebase. If I set:\n> >\n> >   git config pull.ff only\n> >\n> > then we start complaining. And that behavior did change in 2.33.1, but\n> > I'm not sure it's wrong. We have two conflicting config options, and the\n> > precedence for which one we pick switched.\n> >\n> > Do you have that option set in your config? Try:\n> >\n> >   git config --show-origin --show-scope --get-regexp 'pull\\..*'\n> >\n> >\n> > -Peff\n"},{"id":"442392","messageId":"YaG8gUnikxtQs5zx@coredump.intra.peff.net","threadId":"56830","inReplyTo":"CABPp-BGC5DrArqWMiwwpJQgK8WucVcAxj0Ptgpi+_KRb7V7Nwg@mail.gmail.com","subject":"Re: pull.rebase config option broken in 2.33.1","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2021-11-27T05:05:05Z","receivedAt":"2021-11-27T05:07:17Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Nov 26, 2021 at 02:43:44PM -0800, Elijah Newren wrote:\n\n> On Fri, Nov 26, 2021 at 1:45 PM Jeff King <peff@peff.net> wrote:\n> >\n> > On Fri, Nov 26, 2021 at 04:44:52PM -0500, Jeff King wrote:\n> >\n> > > +cc Alex and Elijah from the original 3d5fc24dae (pull: abort if\n> > > --ff-only is given and fast-forwarding is impossible, 2021-07-21) in\n> > > case they have further thoughts, but I _think_ this is working as\n> > > designed.\n> >\n> > Whoops, forgot the cc. Original message in full below.\n> \n> I believe this was already fixed in 2.34.1 in commit ea1954af77\n> (\"pull: should be noop when already-up-to-date\", 2021-11-17).\n\nI thought that at first, too, but this case is a bit different:\n\n> > > In the bug I linked (and what got fixed in 2.34.1), the issue is that\n> > > when the local branch is ahead of the remote, we don't say \"up to date\",\n> > > but complain about fast-forwards.\n> > >\n> > > It's hard to tell from the output above, but it looks like you have a\n> > > case where there are new commits both locally and on the remote? In\n> > > which case a rebase would work just fine.\n\nI think the key thing here is that (AFAICT) the behavior is unchanged\nunless the user has set pull.ff=only explicitly.\n\n-Peff\n"},{"id":"442393","messageId":"CABPp-BGDFiAF=M=n8Ah7LZXk-f75NezF0F=BPD44a4fMrtsD-w@mail.gmail.com","threadId":"56830","inReplyTo":"YaG8gUnikxtQs5zx@coredump.intra.peff.net","subject":"Re: pull.rebase config option broken in 2.33.1","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2021-11-27T05:26:55Z","receivedAt":"2021-11-27T05:29:10Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Fri, Nov 26, 2021 at 9:05 PM Jeff King <peff@peff.net> wrote:\n>\n> On Fri, Nov 26, 2021 at 02:43:44PM -0800, Elijah Newren wrote:\n>\n> > On Fri, Nov 26, 2021 at 1:45 PM Jeff King <peff@peff.net> wrote:\n> > >\n> > > On Fri, Nov 26, 2021 at 04:44:52PM -0500, Jeff King wrote:\n> > >\n> > > > +cc Alex and Elijah from the original 3d5fc24dae (pull: abort if\n> > > > --ff-only is given and fast-forwarding is impossible, 2021-07-21) in\n> > > > case they have further thoughts, but I _think_ this is working as\n> > > > designed.\n> > >\n> > > Whoops, forgot the cc. Original message in full below.\n> >\n> > I believe this was already fixed in 2.34.1 in commit ea1954af77\n> > (\"pull: should be noop when already-up-to-date\", 2021-11-17).\n>\n> I thought that at first, too, but this case is a bit different:\n>\n> > > > In the bug I linked (and what got fixed in 2.34.1), the issue is that\n> > > > when the local branch is ahead of the remote, we don't say \"up to date\",\n> > > > but complain about fast-forwards.\n> > > >\n> > > > It's hard to tell from the output above, but it looks like you have a\n> > > > case where there are new commits both locally and on the remote? In\n> > > > which case a rebase would work just fine.\n>\n> I think the key thing here is that (AFAICT) the behavior is unchanged\n> unless the user has set pull.ff=only explicitly.\n\nAh, I see there were two parts to their report, one of which is the\nissue fixed in 2.34.1.  I'll respond to his original email and ask if\nhe has pull.ff=only set and explain how that interacts with\npull.rebase.\n"},{"id":"442394","messageId":"CABPp-BFdtEB5chYz9tPxJ=M-4U408P7apiROD1-538sb5+aiDg@mail.gmail.com","threadId":"56830","inReplyTo":"YYFEE/2g3SiM04zx@hades.panopticon","subject":"Re: pull.rebase config option broken in 2.33.1","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2021-11-27T05:27:02Z","receivedAt":"2021-11-27T05:29:15Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"Hi Dmitry,\n\nOn Tue, Nov 2, 2021 at 7:09 AM Dmitry Marakasov <amdmi3@amdmi3.ru> wrote:\n>\n> Hi!\n>\n> After update from 2.33.0 to 2.33.1 the pull.rebase = true option\n> no longer works: `git pull` no longer tries to rebase (however manual\n> `git pull --rebase` works fine):\n>\n> % git config pull.rebase\n> true\n> % git pull\n> fatal: Not possible to fast-forward, aborting.\n\nWas pull.ff also set?  As per\nhttps://lore.kernel.org/git/xmqqzgr3pso7.fsf@gitster.g/, --ff-only\noverrides --rebase if both are given on the command line, and by the\nsame token, pull.ff=only will override a pull.rebase=true if both are\nset.\n\nYes, I know it's weird that we have two separate potentially\ncontradictory settings.  A single pull.mode would be better, but the\nbackward compatibility story to migrate is a long story.  Prior to\nv2.33.1/v2.34.0, we had a bunch of untested and mishandled\ninteractions.\n\n> % git pull --rebase\n> Successfully rebased and updated refs/heads/local-fixes.\n\nRight, the command-line options take precedence over config, so if you\nadd pull.ff=only, the --rebase overrides.\n\n> % git pull\n> fatal: Not possible to fast-forward, aborting.\n\nThis was the bug fixed in v2.34.1; see ea1954af77 (\"pull: should be\nnoop when already-up-to-date\", 2021-11-17)\n\n> % grep -C1 rebase .git/config\n> [pull]\n>         rebase = true\n> [rebase]\n>         autostash = true\n>\n> After downgrade to 2.33.0:\n>\n> % git pull\n> Current branch local-fixes is up to date.\n"},{"id":"442875","messageId":"Yajlf6e2aRIpTBqB@hades.panopticon","threadId":"56830","inReplyTo":"YaFViM1tTTAc48ZG@coredump.intra.peff.net","subject":"Re: pull.rebase config option broken in 2.33.1","fromName":"Dmitry Marakasov","fromEmail":"amdmi3@amdmi3.ru","sentAt":"2021-12-02T15:26:05Z","receivedAt":"2021-12-02T15:27:30Z","isPatch":false,"sender":{"key":"amdmi3@amdmi3.ru","avatar":"https://avatars.githubusercontent.com/u/474217?v=4"},"body":"* Jeff King (peff@peff.net) wrote:\n\n> > > > > After update from 2.33.0 to 2.33.1 the pull.rebase = true option\n> > > > > no longer works: `git pull` no longer tries to rebase (however manual\n> > > > > `git pull --rebase` works fine):\n> > > > > \n> > > > > % git config pull.rebase\n> > > > > true\n> > > > > % git pull\n> > > > > fatal: Not possible to fast-forward, aborting.\n> > > > > % git pull --rebase\n> > > > > Successfully rebased and updated refs/heads/local-fixes.\n> > > > > % git pull\n> > > > > fatal: Not possible to fast-forward, aborting.\n> > > > > % grep -C1 rebase .git/config\n> > > > > [pull]\n> > > > > \trebase = true\n> > > > > [rebase]\n> > > > > \tautostash = true\n> > > > > \n> > > > > After downgrade to 2.33.0:\n> > > > > \n> > > > > % git pull\n> > > > > Current branch local-fixes is up to date.\n> > > > \n> > > > This looks like the same bug discussed in:\n> > > > \n> > > >   https://lore.kernel.org/git/CH2PR06MB650424B4205102AC6A48F489B1BD9@CH2PR06MB6504.namprd06.prod.outlook.com/\n> > > > \n> > > > There's a fix in that thread. It's currently in \"next\", but didn't quite\n> > > > make the cutoff for the upcoming v2.34.0.\n> > > \n> > > For the record, the problem is still present in 2.34.1\n> > \n> > In the bug I linked (and what got fixed in 2.34.1), the issue is that\n> > when the local branch is ahead of the remote, we don't say \"up to date\",\n> > but complain about fast-forwards.\n> > \n> > It's hard to tell from the output above, but it looks like you have a\n> > case where there are new commits both locally and on the remote? In\n> > which case a rebase would work just fine.\n> > \n> > But why are we complaining about \"not possible to fast-forward\"? Testing\n> > locally with something like:\n> > \n> > -- >8 --\n> > git init repo\n> > cd repo\n> > \n> > commit() {\n> > \techo $1 >$1\n> > \tgit add $1\n> > \tgit commit -m $1\n> > }\n> > \n> > git checkout -b local\n> > commit base\n> > commit local\n> > \n> > git checkout -b remote HEAD^\n> > commit remote\n> > \n> > git checkout local\n> > git config pull.rebase true\n> > git pull . remote\n> > -- >8 --\n> > \n> > shows that we do rebase. If I set:\n> > \n> >   git config pull.ff only\n> > \n> > then we start complaining. And that behavior did change in 2.33.1, but\n> > I'm not sure it's wrong. We have two conflicting config options, and the\n> > precedence for which one we pick switched.\n> > \n> > Do you have that option set in your config? Try:\n> > \n> >   git config --show-origin --show-scope --get-regexp 'pull\\..*'\n\nYes, I have both `pull.ff=only` and `pull.rebase` set, but these\ncome from different configs:\n\n  % git config --show-origin --show-scope --get-regexp 'pull\\..*'\n  global  file:/home/marakasov/.gitconfig pull.ff only\n  local   file:.git/config    pull.rebase true\n\nIMO the setup is perfectly legal, as I want to disable merge on pull\nin any case, and I also want rebase for a specific repo. So the\nproblem is then in how these options override (not) each other.\n\nThe following change in repo's config fixes this issue for me:\n\n   [pull]\n  +    ff = yes\n       rebase = true\n\nBut IMO it still needs to be fixed in git, as the cause of this\nproblem is quite unobvious and it does not feel right that local\nrepo config should be aware of global config and include explicit\noverrides not really realated to the local repo config, for the\nlatter to work as expected.\n\nIt looks like it could be fixed by either making `pull.rebase` on\nrepo level override `pull.ff` on global level, or reorganizing the\noptions so no override is required, for example by introducing e.g.\n`pull.merge=off` instead of `pull.ff=only`. This way having both\n`pull.merge=off` and `pull.rebase=true` will not contradict each\nother and will not require any cross-variable override logic.\n\n-- \nDmitry Marakasov   .   55B5 0596 FF1E 8D84 5F56  9510 D35A 80DD F9D2 F77D\namdmi3@amdmi3.ru  ..:     https://github.com/AMDmi3  https://amdmi3.ru\n\n"},{"id":"442880","messageId":"CABPp-BFn8kKh1zQqwRSX1+06eNwgAZLfsg9g5LkHepHeZ2ip+Q@mail.gmail.com","threadId":"56830","inReplyTo":"Yajlf6e2aRIpTBqB@hades.panopticon","subject":"Re: pull.rebase config option broken in 2.33.1","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2021-12-02T16:54:12Z","receivedAt":"2021-12-02T16:54:31Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Thu, Dec 2, 2021 at 7:27 AM Dmitry Marakasov <amdmi3@amdmi3.ru> wrote:\n>\n> * Jeff King (peff@peff.net) wrote:\n>\n> > > > > > After update from 2.33.0 to 2.33.1 the pull.rebase = true option\n> > > > > > no longer works: `git pull` no longer tries to rebase (however manual\n> > > > > > `git pull --rebase` works fine):\n> > > > > >\n> > > > > > % git config pull.rebase\n> > > > > > true\n> > > > > > % git pull\n> > > > > > fatal: Not possible to fast-forward, aborting.\n> > > > > > % git pull --rebase\n> > > > > > Successfully rebased and updated refs/heads/local-fixes.\n> > > > > > % git pull\n> > > > > > fatal: Not possible to fast-forward, aborting.\n> > > > > > % grep -C1 rebase .git/config\n> > > > > > [pull]\n> > > > > >       rebase = true\n> > > > > > [rebase]\n> > > > > >       autostash = true\n> > > > > >\n> > > > > > After downgrade to 2.33.0:\n> > > > > >\n> > > > > > % git pull\n> > > > > > Current branch local-fixes is up to date.\n> > > > >\n> > > > > This looks like the same bug discussed in:\n> > > > >\n> > > > >   https://lore.kernel.org/git/CH2PR06MB650424B4205102AC6A48F489B1BD9@CH2PR06MB6504.namprd06.prod.outlook.com/\n> > > > >\n> > > > > There's a fix in that thread. It's currently in \"next\", but didn't quite\n> > > > > make the cutoff for the upcoming v2.34.0.\n> > > >\n> > > > For the record, the problem is still present in 2.34.1\n> > >\n> > > In the bug I linked (and what got fixed in 2.34.1), the issue is that\n> > > when the local branch is ahead of the remote, we don't say \"up to date\",\n> > > but complain about fast-forwards.\n> > >\n> > > It's hard to tell from the output above, but it looks like you have a\n> > > case where there are new commits both locally and on the remote? In\n> > > which case a rebase would work just fine.\n> > >\n> > > But why are we complaining about \"not possible to fast-forward\"? Testing\n> > > locally with something like:\n> > >\n> > > -- >8 --\n> > > git init repo\n> > > cd repo\n> > >\n> > > commit() {\n> > >     echo $1 >$1\n> > >     git add $1\n> > >     git commit -m $1\n> > > }\n> > >\n> > > git checkout -b local\n> > > commit base\n> > > commit local\n> > >\n> > > git checkout -b remote HEAD^\n> > > commit remote\n> > >\n> > > git checkout local\n> > > git config pull.rebase true\n> > > git pull . remote\n> > > -- >8 --\n> > >\n> > > shows that we do rebase. If I set:\n> > >\n> > >   git config pull.ff only\n> > >\n> > > then we start complaining. And that behavior did change in 2.33.1, but\n> > > I'm not sure it's wrong. We have two conflicting config options, and the\n> > > precedence for which one we pick switched.\n> > >\n> > > Do you have that option set in your config? Try:\n> > >\n> > >   git config --show-origin --show-scope --get-regexp 'pull\\..*'\n>\n> Yes, I have both `pull.ff=only` and `pull.rebase` set, but these\n> come from different configs:\n>\n>   % git config --show-origin --show-scope --get-regexp 'pull\\..*'\n>   global  file:/home/marakasov/.gitconfig pull.ff only\n>   local   file:.git/config    pull.rebase true\n>\n> IMO the setup is perfectly legal, as I want to disable merge on pull\n> in any case, and I also want rebase for a specific repo. So the\n> problem is then in how these options override (not) each other.\n>\n> The following change in repo's config fixes this issue for me:\n>\n>    [pull]\n>   +    ff = yes\n\nff is a tri-state -- false, true, or only.  yes is equivalent to true\nand means \"allow but do not require fast forward updates\".\n\n>        rebase = true\n>\n> But IMO it still needs to be fixed in git, as the cause of this\n> problem is quite unobvious and it does not feel right that local\n> repo config should be aware of global config and include explicit\n> overrides not really realated to the local repo config, for the\n> latter to work as expected.\n\nIf you had pull.ff=only and pull.rebase=true in your local config, it\nwould also error out.  Thus, it makes sense that having pull.ff=only\nin global config and pull.rebase=true in local config should error\nout.  The scope at which you get the variables doesn't matter, other\nthan that if you set the same variable in both, clearly local should\noverride global.\n\n> It looks like it could be fixed by either making `pull.rebase` on\n> repo level override `pull.ff` on global level\n\nScopes can only matter when the same config option is set in both\nlocal and global config.  By the time we get to the program logic\ntrying to interpret options, there is no notion of which scope the\nconfig came from.\n\n> , or reorganizing the\n> options so no override is required, for example by introducing e.g.\n> `pull.merge=off` instead of `pull.ff=only`. This way having both\n> `pull.merge=off` and `pull.rebase=true` will not contradict each\n> other and will not require any cross-variable override logic.\n\nYour suggestion to add a third variable to the mix would increase the\nworries of cross-variable override logic, not decrease it.  For\nexample, what if pull.merge=true and pull.rebase=true?  It'd be better\nif we could go back in time and have a single pull.mode instead of\nhaving two options; adding a third would be going in the wrong\ndirection.\n\nAnyway, both merges and rebases are capable of fast-forward updates.\npull.ff=only corresponds to the --ff-only command line option,\ndocumented in git-pull as \"Only update to the new history if there is\nno divergent local history.\"  Thus, that setting is incompatible with\nreconciling divergent changes, which means that neither merging nor\nrebasing should proceed.\n\nIf you usually want to avoid merges & rebases, but in one repo you\nwant to have rebases, then in addition to setting pull.rebase=true\nyou'll also need to override pull.ff by setting it to true (or\nequivalently to 'yes' as you did) in your local config as well.\n"}]}