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

["Randall S. Becker" <rsbecker@nexbridge.com>]

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