{"thread":{"id":"56117","subject":"pull.rebase config vs. --ff-only on command line","startedAt":"2021-07-16T14:50:00Z","lastAt":"2021-07-23T09:43:19Z","messageCount":11,"participants":["Matthias Baumgarten","Elijah Newren","Felipe Contreras","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"430340","messageId":"c62933fb-96b2-99f5-7169-372f486f6e39@aixigo.com","threadId":"56117","inReplyTo":null,"subject":"pull.rebase config vs. --ff-only on command line","fromName":"Matthias Baumgarten","fromEmail":"matthias.baumgarten@aixigo.com","sentAt":"2021-07-16T14:43:10Z","receivedAt":"2021-07-16T14:50:00Z","isPatch":false,"sender":{"key":"matthias.baumgarten@aixigo.com","avatar":null},"body":"Hi,\n\nthis is my first time contacting you guys and girls so I hope this mail \nachieves the expected standard. I've discovered the following behaviour \nof git:\n\nIf pull.rebase is configured to true and git pull --ff-only is executed \nit seems like the config wins, i.e. issuing \"Successfully rebased and \nupdated refs/heads/...\", which is not what I would expect. I always \nbelieved that command line options would overwrite configured options.\n\nIs my assumption that command line options always win wrong or is this a \nbug?\n\nBest regards,\nMatthias\n\n-- \naixigo AG\nKarl-Friedrich-Str. 68, 52072 Aachen, Germany\nphone: +49 (0)241 559709-390, fax: +49 (0)241 559709-99\nemail: matthias.baumgarten@aixigo.com\nweb: https://www.aixigo.com\nDistrict Court Aachen – HRB 8057\nBoard: Christian Friedrich, Tobias Haustein\nChairman of the Supervisory Board: Dr. Roland Schlager\n"},{"id":"430342","messageId":"CABPp-BEHZcfZNL+PG1vmqXGf4Qs3eoULb4NDDgbmOB30HzJu_Q@mail.gmail.com","threadId":"56117","inReplyTo":"c62933fb-96b2-99f5-7169-372f486f6e39@aixigo.com","subject":"Re: pull.rebase config vs. --ff-only on command line","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2021-07-16T15:03:34Z","receivedAt":"2021-07-16T15:03:47Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Fri, Jul 16, 2021 at 7:52 AM Matthias Baumgarten\n wrote:\n>\n> Hi,\n>\n> this is my first time contacting you guys and girls so I hope this mail\n> achieves the expected standard. I've discovered the following behaviour\n> of git:\n>\n> If pull.rebase is configured to true and git pull --ff-only is executed\n> it seems like the config wins, i.e. issuing \"Successfully rebased and\n> updated refs/heads/...\", which is not what I would expect. I always\n> believed that command line options would overwrite configured options.\n>\n> Is my assumption that command line options always win wrong or is this a\n> bug?\n\nIt's a bug.\n"},{"id":"430350","messageId":"60f1b62c7531c_ade9208d8@natae.notmuch","threadId":"56117","inReplyTo":"c62933fb-96b2-99f5-7169-372f486f6e39@aixigo.com","subject":"RE: pull.rebase config vs. --ff-only on command line","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-07-16T16:39:08Z","receivedAt":"2021-07-16T16:39:14Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Hello Matthias,\n\nMatthias Baumgarten wrote:\n> this is my first time contacting you guys and girls so I hope this mail \n> achieves the expected standard. I've discovered the following behaviour \n> of git:\n> \n> If pull.rebase is configured to true and git pull --ff-only is executed \n> it seems like the config wins, i.e. issuing \"Successfully rebased and \n> updated refs/heads/...\", which is not what I would expect. I always \n> believed that command line options would overwrite configured options.\n> \n> Is my assumption that command line options always win wrong or is this a \n> bug?\n\nYes, your assumption is correct, but the equivalent of that combination\nis:\n\n git pull --rebase --ff-only\n\nBut --ff-only is only meant for the merge mode of `git pull`\n(git pull --merge), not the rebase mode, so it's ignored. You can see\nthat from the documentation [1]:\n\n With --ff-only, resolve the merge as a fast-forward when possible.\n When not possible, refuse to merge and exit with a non-zero status.\n\nNote the *merge* part.\n\n[1] https://git-scm.com/docs/git-pull\n\n-- \nFelipe Contreras\n"},{"id":"430352","messageId":"60f1b7853b8a2_ade9208c1@natae.notmuch","threadId":"56117","inReplyTo":"CABPp-BEHZcfZNL+PG1vmqXGf4Qs3eoULb4NDDgbmOB30HzJu_Q@mail.gmail.com","subject":"Re: pull.rebase config vs. --ff-only on command line","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-07-16T16:44:53Z","receivedAt":"2021-07-16T16:44:57Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Elijah Newren wrote:\n> On Fri, Jul 16, 2021 at 7:52 AM Matthias Baumgarten\n> wrote:\n> > this is my first time contacting you guys and girls so I hope this mail\n> > achieves the expected standard. I've discovered the following behaviour\n> > of git:\n> >\n> > If pull.rebase is configured to true and git pull --ff-only is executed\n> > it seems like the config wins, i.e. issuing \"Successfully rebased and\n> > updated refs/heads/...\", which is not what I would expect. I always\n> > believed that command line options would overwrite configured options.\n> >\n> > Is my assumption that command line options always win wrong or is this a\n> > bug?\n> \n> It's a bug.\n\nNo it isn't.\n\nElijah is elevating to fact his opinion of what --ff-only should be\nchanged to.\n\nBut it has not been changed. Today --ff-only is meant only for the merge\nmode of `git pull`, and like other merge-only options (e.g. --ff,\n--no-ff, and --squash) it's ignored in the rebase mode.\n\n-- \nFelipe Contreras\n"},{"id":"430355","messageId":"00b50aa6-9b61-9f80-1d8d-2db3ed5e7638@aixigo.com","threadId":"56117","inReplyTo":"60f1b7853b8a2_ade9208c1@natae.notmuch","subject":"Re: pull.rebase config vs. --ff-only on command line","fromName":"Matthias Baumgarten","fromEmail":"matthias.baumgarten@aixigo.com","sentAt":"2021-07-16T16:54:10Z","receivedAt":"2021-07-16T16:54:20Z","isPatch":false,"sender":{"key":"matthias.baumgarten@aixigo.com","avatar":null},"body":"On 7/16/21 6:44 PM, Felipe Contreras wrote:\n> Elijah Newren wrote:\n>> On Fri, Jul 16, 2021 at 7:52 AM Matthias Baumgarten\n>> wrote:\n>>> this is my first time contacting you guys and girls so I hope this mail\n>>> achieves the expected standard. I've discovered the following behaviour\n>>> of git:\n>>>\n>>> If pull.rebase is configured to true and git pull --ff-only is executed\n>>> it seems like the config wins, i.e. issuing \"Successfully rebased and\n>>> updated refs/heads/...\", which is not what I would expect. I always\n>>> believed that command line options would overwrite configured options.\n>>>\n>>> Is my assumption that command line options always win wrong or is this a\n>>> bug?\n>>\n>> It's a bug.\n> \n> No it isn't.\n> \n> Elijah is elevating to fact his opinion of what --ff-only should be\n> changed to.\n> \n> But it has not been changed. Today --ff-only is meant only for the merge\n> mode of `git pull`, and like other merge-only options (e.g. --ff,\n> --no-ff, and --squash) it's ignored in the rebase mode.\n> \n\nShouldn't every explicitly given merge option (like --ff-only) overwrite \nany configured option that would not even result in a merge, i.e. \nforcing a merge and thus forcing ff-only?\n\n-- \naixigo AG\nKarl-Friedrich-Str. 68, 52072 Aachen, Germany\nphone: +49 (0)241 559709-390, fax: +49 (0)241 559709-99\nemail: matthias.baumgarten@aixigo.com\nweb: https://www.aixigo.com\nDistrict Court Aachen – HRB 8057\nBoard: Christian Friedrich, Tobias Haustein\nChairman of the Supervisory Board: Dr. Roland Schlager\n"},{"id":"430365","messageId":"60f1c9378d5a1_3302085c@natae.notmuch","threadId":"56117","inReplyTo":"00b50aa6-9b61-9f80-1d8d-2db3ed5e7638@aixigo.com","subject":"Re: pull.rebase config vs. --ff-only on command line","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-07-16T18:00:23Z","receivedAt":"2021-07-16T18:00:29Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Matthias Baumgarten wrote:\n> On 7/16/21 6:44 PM, Felipe Contreras wrote:\n> > Elijah Newren wrote:\n> >> On Fri, Jul 16, 2021 at 7:52 AM Matthias Baumgarten\n> >> wrote:\n> >>> this is my first time contacting you guys and girls so I hope this mail\n> >>> achieves the expected standard. I've discovered the following behaviour\n> >>> of git:\n> >>>\n> >>> If pull.rebase is configured to true and git pull --ff-only is executed\n> >>> it seems like the config wins, i.e. issuing \"Successfully rebased and\n> >>> updated refs/heads/...\", which is not what I would expect. I always\n> >>> believed that command line options would overwrite configured options.\n> >>>\n> >>> Is my assumption that command line options always win wrong or is this a\n> >>> bug?\n> >>\n> >> It's a bug.\n> > \n> > No it isn't.\n> > \n> > Elijah is elevating to fact his opinion of what --ff-only should be\n> > changed to.\n> > \n> > But it has not been changed. Today --ff-only is meant only for the merge\n> > mode of `git pull`, and like other merge-only options (e.g. --ff,\n> > --no-ff, and --squash) it's ignored in the rebase mode.\n> \n> Shouldn't every explicitly given merge option (like --ff-only) overwrite \n> any configured option that would not even result in a merge, i.e. \n> forcing a merge and thus forcing ff-only?\n\nPerhaps. Other developers have suggested that before.\n\nThe problem is that everyone wants to make --ff-only the default, and\nthen we start to get into a tricky situation, because what should these\ndo:\n\n git -c pull.ff=only pull\n git -c pull.ff=only pull --merge\n git -c pull.ff=only pull --rebase\n\nOne of these will always fail, when it shouldn't.\n\nI proposed a solution for that, but is has been ignored.\n\n-- \nFelipe Contreras\n"},{"id":"430505","messageId":"fa757764-db25-849d-d8d5-e28908059f6b@aixigo.com","threadId":"56117","inReplyTo":"60f1c9378d5a1_3302085c@natae.notmuch","subject":"Re: pull.rebase config vs. --ff-only on command line","fromName":"Matthias Baumgarten","fromEmail":"matthias.baumgarten@aixigo.com","sentAt":"2021-07-19T14:26:29Z","receivedAt":"2021-07-19T14:26:39Z","isPatch":false,"sender":{"key":"matthias.baumgarten@aixigo.com","avatar":null},"body":"\n\nOn 7/16/21 8:00 PM, Felipe Contreras wrote:\n> Matthias Baumgarten wrote:\n>> On 7/16/21 6:44 PM, Felipe Contreras wrote:\n>>> Elijah Newren wrote:\n>>>> On Fri, Jul 16, 2021 at 7:52 AM Matthias Baumgarten\n>>>> wrote:\n>>>>> this is my first time contacting you guys and girls so I hope this mail\n>>>>> achieves the expected standard. I've discovered the following behaviour\n>>>>> of git:\n>>>>>\n>>>>> If pull.rebase is configured to true and git pull --ff-only is executed\n>>>>> it seems like the config wins, i.e. issuing \"Successfully rebased and\n>>>>> updated refs/heads/...\", which is not what I would expect. I always\n>>>>> believed that command line options would overwrite configured options.\n>>>>>\n>>>>> Is my assumption that command line options always win wrong or is this a\n>>>>> bug?\n>>>>\n>>>> It's a bug.\n>>>\n>>> No it isn't.\n>>>\n>>> Elijah is elevating to fact his opinion of what --ff-only should be\n>>> changed to.\n>>>\n>>> But it has not been changed. Today --ff-only is meant only for the merge\n>>> mode of `git pull`, and like other merge-only options (e.g. --ff,\n>>> --no-ff, and --squash) it's ignored in the rebase mode.\n>>\n>> Shouldn't every explicitly given merge option (like --ff-only) overwrite\n>> any configured option that would not even result in a merge, i.e.\n>> forcing a merge and thus forcing ff-only?\n> \n> Perhaps. Other developers have suggested that before.\n> \n> The problem is that everyone wants to make --ff-only the default, and\n> then we start to get into a tricky situation, because what should these\n> do:\n> \n> git -c pull.ff=only pull\n> git -c pull.ff=only pull --merge\n> git -c pull.ff=only pull --rebase\n\nIf my assumption were true, and every explicit (cli given) option would \noverwrite implicitly given ones (i.e. configured options), wouldn't\n\n * git -c pull.ff=only pull, do a fast-forward (or merge)\n * git -c pull.ff=only pull --merge, force a merge commit\n * git -c pull.ff=only pull --rebase, force rebase\n\n> \n> One of these will always fail, when it shouldn'tWould this even apply under the above assumption?\n> \n> I proposed a solution for that, but is has been ignored.\nI'm sorry!\n> \n\n\n\n-- \naixigo AG\nKarl-Friedrich-Str. 68, 52072 Aachen, Germany\nphone: +49 (0)241 559709-390, fax: +49 (0)241 559709-99\nemail: matthias.baumgarten@aixigo.com\nweb: https://www.aixigo.com\nDistrict Court Aachen – HRB 8057\nBoard: Christian Friedrich, Tobias Haustein\nChairman of the Supervisory Board: Dr. Roland Schlager\n"},{"id":"430523","messageId":"60f5b9a9e29d8_13f2e22084b@natae.notmuch","threadId":"56117","inReplyTo":"fa757764-db25-849d-d8d5-e28908059f6b@aixigo.com","subject":"Re: pull.rebase config vs. --ff-only on command line","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-07-19T17:43:05Z","receivedAt":"2021-07-19T17:49:37Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Matthias Baumgarten wrote:\n> On 7/16/21 8:00 PM, Felipe Contreras wrote:\n> > Matthias Baumgarten wrote:\n> >> On 7/16/21 6:44 PM, Felipe Contreras wrote:\n> >>> Elijah Newren wrote:\n> >>>> On Fri, Jul 16, 2021 at 7:52 AM Matthias Baumgarten\n> >>>> wrote:\n> >>>>> this is my first time contacting you guys and girls so I hope this mail\n> >>>>> achieves the expected standard. I've discovered the following behaviour\n> >>>>> of git:\n> >>>>>\n> >>>>> If pull.rebase is configured to true and git pull --ff-only is executed\n> >>>>> it seems like the config wins, i.e. issuing \"Successfully rebased and\n> >>>>> updated refs/heads/...\", which is not what I would expect. I always\n> >>>>> believed that command line options would overwrite configured options.\n> >>>>>\n> >>>>> Is my assumption that command line options always win wrong or is this a\n> >>>>> bug?\n> >>>>\n> >>>> It's a bug.\n> >>>\n> >>> No it isn't.\n> >>>\n> >>> Elijah is elevating to fact his opinion of what --ff-only should be\n> >>> changed to.\n> >>>\n> >>> But it has not been changed. Today --ff-only is meant only for the merge\n> >>> mode of `git pull`, and like other merge-only options (e.g. --ff,\n> >>> --no-ff, and --squash) it's ignored in the rebase mode.\n> >>\n> >> Shouldn't every explicitly given merge option (like --ff-only) overwrite\n> >> any configured option that would not even result in a merge, i.e.\n> >> forcing a merge and thus forcing ff-only?\n> > \n> > Perhaps. Other developers have suggested that before.\n> > \n> > The problem is that everyone wants to make --ff-only the default, and\n> > then we start to get into a tricky situation, because what should these\n> > do:\n> > \n> > git -c pull.ff=only pull\n> > git -c pull.ff=only pull --merge\n> > git -c pull.ff=only pull --rebase\n> \n> If my assumption were true, and every explicit (cli given) option would \n> overwrite implicitly given ones (i.e. configured options), wouldn't\n> \n> * git -c pull.ff=only pull, do a fast-forward (or merge)\n> * git -c pull.ff=only pull --merge, force a merge commit\n> * git -c pull.ff=only pull --rebase, force rebase\n\nThe documentation says --ff-only is meant for merges, therefore these\nthree should be valid and do the same:\n\n git pull --ff-only # --merge is the default\n git pull --merge --ff-only\n git pull --ff-only --merge\n\nIn order for your assumption above to be correct, the semantics of\n--ff-only have to be changed (along with the documentation), but people\nare *already* relying on the current semantics:\n\n [pull]\n ff = only\n rebase = true\n\nI made a poll on reddit [1], and 19% (so far) said they do use both\nconfigurations, and they know what `git pull --no-rebase` would do.\n\nIn other words: they would expect `git pull` to do a rebase, but\n`git pull --merge` to do a fast-forward merge.\n\nChanging the semantics of --ff-only would break behavior they rely on,\nunless we break symmetry from --ff-only and pull.ff=only which would be\nvery hard to explain the documentation.\n\n\nHowever, if --ff-only wasn't mapped to pull.ff=only, but\npull.mode=fast-forward, then we can have both: the configurations people\nrely on today wouldn't be broken, and your expectation that\n`git pull --ff-only` overrides pull.mode=rebase would be met.\n\nIt's the perfect solution.\n\n> > One of these will always fail, when it shouldn't\n> Would this even apply under the above assumption?\n\n[I think you meant to paste this]\n\nUnder your assumption it wouldn't fail, but other behavior users rely on\ntoday would be broken.\n\n> > I proposed a solution for that, but is has been ignored.\n> I'm sorry!\n\nIt's not me the one that suffers (I don't even use `git pull`), it's the\nusers that have been negatively affected for more than ten years.\n\n[1] https://www.reddit.com/r/git/comments/omcngl/do_you_use_both_pullff_and_pullrebase/\n\n-- \nFelipe Contreras\n"},{"id":"430945","messageId":"xmqq7dhi9nxv.fsf@gitster.g","threadId":"56117","inReplyTo":"fa757764-db25-849d-d8d5-e28908059f6b@aixigo.com","subject":"Re: pull.rebase config vs. --ff-only on command line","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-07-22T18:57:16Z","receivedAt":"2021-07-22T18:57:23Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthias Baumgarten writes:\n\n> If my assumption were true, and every explicit (cli given) option\n> would overwrite implicitly given ones (i.e. configured options),\n> wouldn't\n>\n> * git -c pull.ff=only pull, do a fast-forward (or merge)\n\nThis should fast-forward if it can or otherwise fail if it cannot,\nright?\n\n> * git -c pull.ff=only pull --merge, force a merge commit\n\nThis would fast-forward if it can or otherwise create a merge.\nUnlike \"pull --no-ff\", this should not \"force\" a merge commit.\n\n> * git -c pull.ff=only pull --rebase, force rebase\n\nThis would rebase (we may not have our own commits on top of theirs,\nin which case it would end up fast-forwarding plus rebasing 0\ncommits).\n\nI do not think the phrase \"force rebase\" makes much sense, though.\n"},{"id":"430967","messageId":"60f9eca348290_678a208fb@natae.notmuch","threadId":"56117","inReplyTo":"xmqq7dhi9nxv.fsf@gitster.g","subject":"Re: pull.rebase config vs. --ff-only on command line","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-07-22T22:09:39Z","receivedAt":"2021-07-22T22:09:43Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Junio C Hamano wrote:\n> Matthias Baumgarten writes:\n\n> > * git -c pull.ff=only pull --merge, force a merge commit\n> \n> This would fast-forward if it can or otherwise create a merge.\n> Unlike \"pull --no-ff\", this should not \"force\" a merge commit.\n\nToday people rely on this doing a fast-forward-only merge (with\n--no-rebase).\n\nChanging this would break existing behavior they rely on.\n\nIt's not hypothetical [1].\n\n[1] https://www.reddit.com/r/git/comments/omcngl/do_you_use_both_pullff_and_pullrebase/\n\n-- \nFelipe Contreras\n"},{"id":"431014","messageId":"ed3f7289-0893-5199-a7ca-087604aee029@aixigo.com","threadId":"56117","inReplyTo":"xmqq7dhi9nxv.fsf@gitster.g","subject":"Re: pull.rebase config vs. --ff-only on command line","fromName":"Matthias Baumgarten","fromEmail":"matthias.baumgarten@aixigo.com","sentAt":"2021-07-23T09:36:30Z","receivedAt":"2021-07-23T09:43:19Z","isPatch":false,"sender":{"key":"matthias.baumgarten@aixigo.com","avatar":null},"body":"On 7/22/21 8:57 PM, Junio C Hamano wrote:\n>> * git -c pull.ff=only pull, do a fast-forward (or merge)\n> \n> This should fast-forward if it can or otherwise fail if it cannot,\n> right?\n\nYes, I should not have written \"... (or merge)\".\n\n>> * git -c pull.ff=only pull --merge, force a merge commit\n> \n> This would fast-forward if it can or otherwise create a merge.\n> Unlike \"pull --no-ff\", this should not \"force\" a merge commit.\n\nAck. I.e. it should work like \"git merge\" would by default.\n\n>> * git -c pull.ff=only pull --rebase, force rebase\n> \n> This would rebase (we may not have our own commits on top of theirs,\n> in which case it would end up fast-forwarding plus rebasing 0\n> commits).\n\nYes. Again, this should and would behave like e.g. \"git rebase\" would if \nI were to rebase a branch which is a few commits _behind_ the branch I \nrebase on top of.\n\n> I do not think the phrase \"force rebase\" makes much sense, though.\nAgree.\n\n\n-- \naixigo AG\nKarl-Friedrich-Str. 68, 52072 Aachen, Germany\nphone: +49 (0)241 559709-390, fax: +49 (0)241 559709-99\nemail: matthias.baumgarten@aixigo.com\nweb: https://www.aixigo.com\nDistrict Court Aachen – HRB 8057\nBoard: Christian Friedrich, Tobias Haustein\nChairman of the Supervisory Board: Dr. Roland Schlager\n"}]}