Re: Why does `pull.rebase` default to `false`?

[Elijah Newren <newren@gmail.com>]

On Fri, Feb 28, 2020 at 10:17 AM Robert Dailey <rcdailey.lists@gmail.com> 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.