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

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

[Robert Dailey]

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!

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

[Randall S. Becker]

On February 28, 2020 1:15 PM, Robert Dailey wrote:
> To: Git <git@vger.kernel.org>
> Subject: Why does `pull.rebase` default to `false`?
> 
> 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!

Coming 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 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.

One 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.

My $0.02 and opinion,
Randall

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

[Elijah Newren]

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.

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

[Junio C Hamano]

Elijah Newren <newren@gmail.com> writes:

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

While it is true that it would make no sense for integrators to
rebase (in fact it would be a grave sin for them to do so), I do
not think the choice of the default has much to do with it.

Whether you keep your work on topic branches, or you only work on a
single thing at a time and use master for it, an individual
contributor who is working on a project (be it small or large) can
do 'pull --rebase' on each topic branch to keep up with the updated
upstream, but it quickly becomes unpleansant once the topics start
to get interrelated.  And at that point, leaving your 'master' clean
and only run "pull --ff-only" there, and after doing it once,
rebasing your multiple topics locally on top of the updated upstream
(or your 'master', which is a clean copy of it), would start to make
more sense.  And once you start doing that, the only 'pull' you'd do
would be 'pull --ff-only', and at that point the default value of
pull.rebase no longer matters.

Sarcastically put, setting pull.rebase=true may become a way to
ensure that a newbie stays a newbie who does not learn to juggle
multiple related branches, because only the simplest thing becomes
easier with the setting.

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

[Konstantin Tokarev]

28.02.2020, 23:17, "Junio C Hamano" <gitster@pobox.com>:
> Elijah Newren <newren@gmail.com> writes:
>
>>  On Fri, Feb 28, 2020 at 10:17 AM Robert Dailey <rcdailey.lists@gmail.com> wrote:
>>>  ...
>>>  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.
>>  ...
>>  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.
>
> While it is true that it would make no sense for integrators to
> rebase (in fact it would be a grave sin for them to do so), I do
> not think the choice of the default has much to do with it.
>
> Whether you keep your work on topic branches, or you only work on a
> single thing at a time and use master for it, an individual
> contributor who is working on a project (be it small or large) can
> do 'pull --rebase' on each topic branch to keep up with the updated
> upstream, but it quickly becomes unpleansant once the topics start
> to get interrelated. And at that point, leaving your 'master' clean
> and only run "pull --ff-only" there, and after doing it once,
> rebasing your multiple topics locally on top of the updated upstream
> (or your 'master', which is a clean copy of it), would start to make
> more sense. And once you start doing that, the only 'pull' you'd do
> would be 'pull --ff-only', and at that point the default value of
> pull.rebase no longer matters.
>
> Sarcastically put, setting pull.rebase=true may become a way to
> ensure that a newbie stays a newbie who does not learn to juggle
> multiple related branches, because only the simplest thing becomes
> easier with the setting.

In reality, newbies often end up doing chaotic merges caused by pull
instead of learning about rebase and branches. IMO, it would be better
to have pull.ff=only as a default.



-- 
Regards,
Konstantin

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

[Robert Dailey]

On Fri, Feb 28, 2020 at 3:10 PM Konstantin Tokarev <annulen@yandex.ru> wrote:
> In reality, newbies often end up doing chaotic merges caused by pull
> instead of learning about rebase and branches. IMO, it would be better
> to have pull.ff=only as a default.

You and Junio make a really good point. After reading the responses, I
definitely could reword my problem statement. The problem is that, for
newbie git users (the majority of people I work with), they just do
`git pull` which always does a merge. Myself (and many others) in
simple workflows don't like it when newbies do merges on a pull.

So the problem statement is: Prevent newbies from doing a merge commit
on pull. Whether its a rebase or not is beside the point. I think
making it --ff-only would solve the issue nicely. It forces them to
make their intention explicit: Ether do a merge pull, or a rebase
pull. But you are forcing them to pick (and ultimately get educated).

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

[Konstantin Tokarev]

29.02.2020, 00:23, "Robert Dailey" <rcdailey.lists@gmail.com>:
> On Fri, Feb 28, 2020 at 3:10 PM Konstantin Tokarev <annulen@yandex.ru> wrote:
>>  In reality, newbies often end up doing chaotic merges caused by pull
>>  instead of learning about rebase and branches. IMO, it would be better
>>  to have pull.ff=only as a default.
>
> You and Junio make a really good point. After reading the responses, I
> definitely could reword my problem statement. The problem is that, for
> newbie git users (the majority of people I work with), they just do
> `git pull` which always does a merge. Myself (and many others) in
> simple workflows don't like it when newbies do merges on a pull.

And if default behavior would suddenly be switched to pull.rebase=true, newbie
who was doing these merges all the way may end up in a really nasty situation 
when doing pull: rebasing local master which may already contain a few local
merges not present in origin/master, resulting in complete change of recent history
shape and possibly some involving a few bad conflicts. Changing default to
pull.ff=only seems to be less likely to wreak havoc.

>
> So the problem statement is: Prevent newbies from doing a merge commit
> on pull. Whether its a rebase or not is beside the point. I think
> making it --ff-only would solve the issue nicely. It forces them to
> make their intention explicit: Ether do a merge pull, or a rebase
> pull. But you are forcing them to pick (and ultimately get educated).

-- 
Regards,
Konstantin

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

[Alex Henrie]

On Fri, Feb 28, 2020 at 2:23 PM Robert Dailey <rcdailey.lists@gmail.com> wrote:
>
> So the problem statement is: Prevent newbies from doing a merge commit
> on pull. Whether its a rebase or not is beside the point. I think
> making it --ff-only would solve the issue nicely. It forces them to
> make their intention explicit: Ether do a merge pull, or a rebase
> pull. But you are forcing them to pick (and ultimately get educated).

I actually wrote a patch that prints a warning on `git pull` if the
user has not set pull.rebase in their config file or specified
--rebase, --no-rebase, or --ff-only on the command line, but I haven't
submitted it because I figured that it would start a big argument on
the mailing list. Since that argument has now already started, I
should probably just send the patch.

-Alex