{"thread":{"id":"52912","subject":"Why does `pull.rebase` default to `false`?","startedAt":"2020-02-28T18:15:46Z","lastAt":"2020-02-28T21:53:29Z","messageCount":8,"participants":["Robert Dailey","Randall S. Becker","Elijah Newren","Junio C Hamano","Konstantin Tokarev","Alex Henrie"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"392677","messageId":"CAHd499DC7pOB3kD7nAG79GrufKrV-8p4vSZ5ZEPQb5gdXrNakg@mail.gmail.com","threadId":"52912","inReplyTo":null,"subject":"Why does `pull.rebase` default to `false`?","fromName":"Robert Dailey","fromEmail":"rcdailey.lists@gmail.com","sentAt":"2020-02-28T18:15:29Z","receivedAt":"2020-02-28T18:15:46Z","isPatch":false,"sender":{"key":"rcdailey.lists@gmail.com","avatar":null},"body":"This is more of a question of practicality. Literally all of the team\nand project workflows I've experienced have demanded that `git pull`\nactually perform a rebase of your local commits, as opposed to\nintroducing a merge commit. This means setting `pull.rebase` to\n`true`. I can't think of a practical, day-to-day use case for wanting\nmerge commits after a pull. Since the subject commits of the rebase\nare always local, there's no harm to anything upstream since they\nhaven't been pushed yet.\n\nI'm sure there are edge cases that explain why the default is `false`,\nbut I'd argue that it is likely a case of the minority concerns\nbecoming an inconvenience for the majority of users.\n\nThanks in advance for any enlightenment!\n"},{"id":"392680","messageId":"00f101d5ee68$7fa0ed00$7ee2c700$@nexbridge.com","threadId":"52912","inReplyTo":"CAHd499DC7pOB3kD7nAG79GrufKrV-8p4vSZ5ZEPQb5gdXrNakg@mail.gmail.com","subject":"RE: Why does `pull.rebase` default to `false`?","fromName":"Randall S. Becker","fromEmail":"rsbecker@nexbridge.com","sentAt":"2020-02-28T18:54:20Z","receivedAt":"2020-02-28T18:54:31Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On February 28, 2020 1:15 PM, Robert Dailey wrote:\n> To: Git \n> Subject: Why does `pull.rebase` default to `false`?\n> \n> This is more of a question of practicality. Literally all of the team and project\n> workflows I've experienced have demanded that `git pull` actually perform a\n> rebase of your local commits, as opposed to introducing a merge commit.\n> This means setting `pull.rebase` to `true`. I can't think of a practical, day-to-\n> day use case for wanting merge commits after a pull. Since the subject\n> commits of the rebase are always local, there's no harm to anything\n> upstream since they haven't been pushed yet.\n> \n> I'm sure there are edge cases that explain why the default is `false`, but I'd\n> argue that it is likely a case of the minority concerns becoming an\n> inconvenience for the majority of users.\n> \n> Thanks in advance for any enlightenment!\n\nComing at this from the pull.rebase=false camp, we do not use rebase except in extenuating circumstances in our workflows to correct a poorly constructed commit chain. Merge is almost always preferable. Our topic branches are shared with our BitBucket and Gitlab instances so others can see and learn what is going on - so changes are not strictly local (commit/push is preferred at end of day in case of machine crash/loss from an overnight OS update - happened to our team twice last year). Some of our longer duration topic branches have evolved into temporary sub-integration streams with their own Pull requests until they are finally closed back to master. Random rewriting of history, even on topic branches, would confuse the SHA out of everyone. To us, a merge on a topic branch indicates an explicit \"catch up\" from origin, which would otherwise require detective work, inferences, and analysis after someone else tries to make sense of what a rebase did prior to a Pull request. There is\n then also the risk that your Pull request will include irrelevant commits that were already covered by a prior Pull request because signatures have changed since the common merge point - while the diff effect and signatures at the end are the same, the parent commit chains can be longer and less reflective of the actual work being done - and screws up our change metrics something terrible, making it look like we are change code far more than we actually are. The rebase paradigm may have worked for other VCS systems (thinking of ClearCase here), but requiring rebase on pull would make that git workflow unpalatable.\n\nOne thing really important in context is that we never work on master locally, and only work on our main development/integration branch during release packaging activities if a topic branch will not work nicely - restricted set of people. We secure all main branches (in GitFlow), to prevent push/rewrite. Everything has to go through a Pull request. Our policy is that developers have to do their work on their own personal topic branches. That applies to shared fix branches also, which take in a GitFlow methodology while they exist.\n\nMy $0.02 and opinion,\nRandall\n\n\n"},{"id":"392682","messageId":"CABPp-BGrwNf9p6Ayu=A4CF9ydww8tQfvzFqFO1rNm-QG55yG6w@mail.gmail.com","threadId":"52912","inReplyTo":"CAHd499DC7pOB3kD7nAG79GrufKrV-8p4vSZ5ZEPQb5gdXrNakg@mail.gmail.com","subject":"Re: Why does `pull.rebase` default to `false`?","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2020-02-28T18:56:34Z","receivedAt":"2020-02-28T18:56:48Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Fri, Feb 28, 2020 at 10:17 AM Robert Dailey wrote:\n>\n> This is more of a question of practicality. Literally all of the team\n> and project workflows I've experienced have demanded that `git pull`\n> actually perform a rebase of your local commits, as opposed to\n> introducing a merge commit. This means setting `pull.rebase` to\n> `true`. I can't think of a practical, day-to-day use case for wanting\n> merge commits after a pull. Since the subject commits of the rebase\n> are always local, there's no harm to anything upstream since they\n> haven't been pushed yet.\n>\n> I'm sure there are edge cases that explain why the default is `false`,\n> but I'd argue that it is likely a case of the minority concerns\n> becoming an inconvenience for the majority of users.\n>\n> Thanks in advance for any enlightenment!\n\nThe default of pull.rebase being false makes a lot of sense for Linus\nor any of his lieutenants, or any one else in an integrator-like\nworkflow.\n\nIt could also be viewed as measuring authoritativeness of\nrepositories; if your current repository is more authoritative than\nwhat you are pulling from (as is the case for Linus or his\nlieutenants) then you will likely want pull.rebase to be false. If it\nis less authoritative (e.g. you have a central repository and you are\njust a contributor), you may likely benefit from pull.rebase being\ntrue.\n\nI think pushing to central repositories is a far more common workflow\nthan being an integrator, but we should be careful about only\nconsidering that. For example, although at work we predominantly have\na push-to-central-repository workflow, we periodically have people\nmerging previously independent repos together (creating a monorepo\nfrom separate repos). This is often done with git pull\n--allow-unrelated-histories. If pull.rebase were to suddenly switch\nto true, folks that built up knowledge about how to do these merges\nwould get some negative surprises. Although\n--allow-unrelated-histories was the first example to spring to my\nmind, I suspect that whenever the user has merges in their history\nthat the other side doesn't, that a default switch of pull.rebase to\ntrue could be a negative surprise.\n\nThere was a fairly similar history for push.default; for a long time\nit defaulted to what we now call \"matching\" because it made sense for\nthe original workflow of integrator and lieutenants that git had been\ndesigned for. Then we discovered it was really bad for people who\npushed to centralized repositories instead, and invented new terms\n(upstream, tracking, simple) and changed the default over time.\n\nWe may want to do something similar with pull.rebase (only let it\nsucceed if it's a fast-forward by default, otherwise require the user\nto set pull.rebase first?), but I don't want to have to think through\nthe details or work on such a transition -- I'm just commenting with\nsome thoughts that might help you understand the current state. And\nothers probably have more details than me.\n"},{"id":"392686","messageId":"xmqq8skmeabd.fsf@gitster-ct.c.googlers.com","threadId":"52912","inReplyTo":"CABPp-BGrwNf9p6Ayu=A4CF9ydww8tQfvzFqFO1rNm-QG55yG6w@mail.gmail.com","subject":"Re: Why does `pull.rebase` default to `false`?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-02-28T20:17:10Z","receivedAt":"2020-02-28T20:17:21Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Elijah Newren writes:\n\n> On Fri, Feb 28, 2020 at 10:17 AM Robert Dailey wrote:\n>> ...\n>> I'm sure there are edge cases that explain why the default is `false`,\n>> but I'd argue that it is likely a case of the minority concerns\n>> becoming an inconvenience for the majority of users.\n>>\n>> Thanks in advance for any enlightenment!\n>\n> The default of pull.rebase being false makes a lot of sense for Linus\n> or any of his lieutenants, or any one else in an integrator-like\n> workflow.\n> ...\n> We may want to do something similar with pull.rebase (only let it\n> succeed if it's a fast-forward by default, otherwise require the user\n> to set pull.rebase first?), but I don't want to have to think through\n> the details or work on such a transition -- I'm just commenting with\n> some thoughts that might help you understand the current state. And\n> others probably have more details than me.\n\nWhile it is true that it would make no sense for integrators to\nrebase (in fact it would be a grave sin for them to do so), I do\nnot think the choice of the default has much to do with it.\n\nWhether you keep your work on topic branches, or you only work on a\nsingle thing at a time and use master for it, an individual\ncontributor who is working on a project (be it small or large) can\ndo 'pull --rebase' on each topic branch to keep up with the updated\nupstream, but it quickly becomes unpleansant once the topics start\nto get interrelated. And at that point, leaving your 'master' clean\nand only run \"pull --ff-only\" there, and after doing it once,\nrebasing your multiple topics locally on top of the updated upstream\n(or your 'master', which is a clean copy of it), would start to make\nmore sense. And once you start doing that, the only 'pull' you'd do\nwould be 'pull --ff-only', and at that point the default value of\npull.rebase no longer matters.\n\nSarcastically put, setting pull.rebase=true may become a way to\nensure that a newbie stays a newbie who does not learn to juggle\nmultiple related branches, because only the simplest thing becomes\neasier with the setting.\n\n\n"},{"id":"392690","messageId":"1320071582924243@iva6-ab1cb434301d.qloud-c.yandex.net","threadId":"52912","inReplyTo":"xmqq8skmeabd.fsf@gitster-ct.c.googlers.com","subject":"Re: Why does `pull.rebase` default to `false`?","fromName":"Konstantin Tokarev","fromEmail":"annulen@yandex.ru","sentAt":"2020-02-28T21:10:43Z","receivedAt":"2020-02-28T21:16:21Z","isPatch":false,"sender":{"key":"annulen@yandex.ru","avatar":null},"body":"\n\n28.02.2020, 23:17, \"Junio C Hamano\" :\n> Elijah Newren writes:\n>\n>>  On Fri, Feb 28, 2020 at 10:17 AM Robert Dailey wrote:\n>>>  ...\n>>>  I'm sure there are edge cases that explain why the default is `false`,\n>>>  but I'd argue that it is likely a case of the minority concerns\n>>>  becoming an inconvenience for the majority of users.\n>>>\n>>>  Thanks in advance for any enlightenment!\n>>\n>>  The default of pull.rebase being false makes a lot of sense for Linus\n>>  or any of his lieutenants, or any one else in an integrator-like\n>>  workflow.\n>>  ...\n>>  We may want to do something similar with pull.rebase (only let it\n>>  succeed if it's a fast-forward by default, otherwise require the user\n>>  to set pull.rebase first?), but I don't want to have to think through\n>>  the details or work on such a transition -- I'm just commenting with\n>>  some thoughts that might help you understand the current state. And\n>>  others probably have more details than me.\n>\n> While it is true that it would make no sense for integrators to\n> rebase (in fact it would be a grave sin for them to do so), I do\n> not think the choice of the default has much to do with it.\n>\n> Whether you keep your work on topic branches, or you only work on a\n> single thing at a time and use master for it, an individual\n> contributor who is working on a project (be it small or large) can\n> do 'pull --rebase' on each topic branch to keep up with the updated\n> upstream, but it quickly becomes unpleansant once the topics start\n> to get interrelated. And at that point, leaving your 'master' clean\n> and only run \"pull --ff-only\" there, and after doing it once,\n> rebasing your multiple topics locally on top of the updated upstream\n> (or your 'master', which is a clean copy of it), would start to make\n> more sense. And once you start doing that, the only 'pull' you'd do\n> would be 'pull --ff-only', and at that point the default value of\n> pull.rebase no longer matters.\n>\n> Sarcastically put, setting pull.rebase=true may become a way to\n> ensure that a newbie stays a newbie who does not learn to juggle\n> multiple related branches, because only the simplest thing becomes\n> easier with the setting.\n\nIn reality, newbies often end up doing chaotic merges caused by pull\ninstead of learning about rebase and branches. IMO, it would be better\nto have pull.ff=only as a default.\n\n\n\n-- \nRegards,\nKonstantin\n\n"},{"id":"392691","messageId":"CAHd499B3HbXPo+O3u3qA-SfJ_dV=z2k5v09mVHtbjXGkAaNBvQ@mail.gmail.com","threadId":"52912","inReplyTo":"1320071582924243@iva6-ab1cb434301d.qloud-c.yandex.net","subject":"Re: Why does `pull.rebase` default to `false`?","fromName":"Robert Dailey","fromEmail":"rcdailey.lists@gmail.com","sentAt":"2020-02-28T21:22:54Z","receivedAt":"2020-02-28T21:23:10Z","isPatch":false,"sender":{"key":"rcdailey.lists@gmail.com","avatar":null},"body":"On Fri, Feb 28, 2020 at 3:10 PM Konstantin Tokarev wrote:\n> In reality, newbies often end up doing chaotic merges caused by pull\n> instead of learning about rebase and branches. IMO, it would be better\n> to have pull.ff=only as a default.\n\nYou and Junio make a really good point. After reading the responses, I\ndefinitely could reword my problem statement. The problem is that, for\nnewbie git users (the majority of people I work with), they just do\n`git pull` which always does a merge. Myself (and many others) in\nsimple workflows don't like it when newbies do merges on a pull.\n\nSo the problem statement is: Prevent newbies from doing a merge commit\non pull. Whether its a rebase or not is beside the point. I think\nmaking it --ff-only would solve the issue nicely. It forces them to\nmake their intention explicit: Ether do a merge pull, or a rebase\npull. But you are forcing them to pick (and ultimately get educated).\n"},{"id":"392692","messageId":"1200001582926410@vla1-fadba9086fdf.qloud-c.yandex.net","threadId":"52912","inReplyTo":"CAHd499B3HbXPo+O3u3qA-SfJ_dV=z2k5v09mVHtbjXGkAaNBvQ@mail.gmail.com","subject":"Re: Why does `pull.rebase` default to `false`?","fromName":"Konstantin Tokarev","fromEmail":"annulen@yandex.ru","sentAt":"2020-02-28T21:46:50Z","receivedAt":"2020-02-28T21:47:00Z","isPatch":false,"sender":{"key":"annulen@yandex.ru","avatar":null},"body":"\n\n29.02.2020, 00:23, \"Robert Dailey\" :\n> On Fri, Feb 28, 2020 at 3:10 PM Konstantin Tokarev wrote:\n>>  In reality, newbies often end up doing chaotic merges caused by pull\n>>  instead of learning about rebase and branches. IMO, it would be better\n>>  to have pull.ff=only as a default.\n>\n> You and Junio make a really good point. After reading the responses, I\n> definitely could reword my problem statement. The problem is that, for\n> newbie git users (the majority of people I work with), they just do\n> `git pull` which always does a merge. Myself (and many others) in\n> simple workflows don't like it when newbies do merges on a pull.\n\nAnd if default behavior would suddenly be switched to pull.rebase=true, newbie\nwho was doing these merges all the way may end up in a really nasty situation \nwhen doing pull: rebasing local master which may already contain a few local\nmerges not present in origin/master, resulting in complete change of recent history\nshape and possibly some involving a few bad conflicts. Changing default to\npull.ff=only seems to be less likely to wreak havoc.\n\n>\n> So the problem statement is: Prevent newbies from doing a merge commit\n> on pull. Whether its a rebase or not is beside the point. I think\n> making it --ff-only would solve the issue nicely. It forces them to\n> make their intention explicit: Ether do a merge pull, or a rebase\n> pull. But you are forcing them to pick (and ultimately get educated).\n\n-- \nRegards,\nKonstantin\n\n"},{"id":"392693","messageId":"CAMMLpeTheUdUx0GZL2pQybewkPM2d-NB1-zvV9qu=VOzrMiddg@mail.gmail.com","threadId":"52912","inReplyTo":"CAHd499B3HbXPo+O3u3qA-SfJ_dV=z2k5v09mVHtbjXGkAaNBvQ@mail.gmail.com","subject":"Re: Why does `pull.rebase` default to `false`?","fromName":"Alex Henrie","fromEmail":"alexhenrie24@gmail.com","sentAt":"2020-02-28T21:53:12Z","receivedAt":"2020-02-28T21:53:29Z","isPatch":false,"sender":{"key":"alexhenrie24@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5951993?v=4"},"body":"On Fri, Feb 28, 2020 at 2:23 PM Robert Dailey wrote:\n>\n> So the problem statement is: Prevent newbies from doing a merge commit\n> on pull. Whether its a rebase or not is beside the point. I think\n> making it --ff-only would solve the issue nicely. It forces them to\n> make their intention explicit: Ether do a merge pull, or a rebase\n> pull. But you are forcing them to pick (and ultimately get educated).\n\nI actually wrote a patch that prints a warning on `git pull` if the\nuser has not set pull.rebase in their config file or specified\n--rebase, --no-rebase, or --ff-only on the command line, but I haven't\nsubmitted it because I figured that it would start a big argument on\nthe mailing list. Since that argument has now already started, I\nshould probably just send the patch.\n\n-Alex\n"}]}