On Fri, Feb 28, 2020 at 10:17 AM Robert Dailey <rcdailey.lists@xxxxxxxxx> wrote: > > This is more of a question of practicality. Literally all of the team > and project workflows I've experienced have demanded that `git pull` > actually perform a rebase of your local commits, as opposed to > introducing a merge commit. This means setting `pull.rebase` to > `true`. I can't think of a practical, day-to-day use case for wanting > merge commits after a pull. Since the subject commits of the rebase > are always local, there's no harm to anything upstream since they > haven't been pushed yet. > > I'm sure there are edge cases that explain why the default is `false`, > but I'd argue that it is likely a case of the minority concerns > becoming an inconvenience for the majority of users. > > Thanks in advance for any enlightenment! The default of pull.rebase being false makes a lot of sense for Linus or any of his lieutenants, or any one else in an integrator-like workflow. It could also be viewed as measuring authoritativeness of repositories; if your current repository is more authoritative than what you are pulling from (as is the case for Linus or his lieutenants) then you will likely want pull.rebase to be false. If it is less authoritative (e.g. you have a central repository and you are just a contributor), you may likely benefit from pull.rebase being true. I think pushing to central repositories is a far more common workflow than being an integrator, but we should be careful about only considering that. For example, although at work we predominantly have a push-to-central-repository workflow, we periodically have people merging previously independent repos together (creating a monorepo from separate repos). This is often done with git pull --allow-unrelated-histories. If pull.rebase were to suddenly switch to true, folks that built up knowledge about how to do these merges would get some negative surprises. Although --allow-unrelated-histories was the first example to spring to my mind, I suspect that whenever the user has merges in their history that the other side doesn't, that a default switch of pull.rebase to true could be a negative surprise. There was a fairly similar history for push.default; for a long time it defaulted to what we now call "matching" because it made sense for the original workflow of integrator and lieutenants that git had been designed for. Then we discovered it was really bad for people who pushed to centralized repositories instead, and invented new terms (upstream, tracking, simple) and changed the default over time. We may want to do something similar with pull.rebase (only let it succeed if it's a fast-forward by default, otherwise require the user to set pull.rebase first?), but I don't want to have to think through the details or work on such a transition -- I'm just commenting with some thoughts that might help you understand the current state. And others probably have more details than me.
