git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
RDRobert Dailey <rcdailey.lists@gmail.com>
Date
Feb 28, 2020, 18:15 UTC
Message-ID
<CAHd499DC7pOB3kD7nAG79GrufKrV-8p4vSZ5ZEPQb5gdXrNakg@mail.gmail.com>

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!
Next: Randall S. Becker
Message 1 of 8 in “Why does `pull.rebase` default to `false`?”
  1. Robert DaileyFeb 28, 2020
  2. Randall S. BeckerFeb 28, 2020
  3. Elijah NewrenFeb 28, 2020
  4. Junio C HamanoFeb 28, 2020
  5. Konstantin TokarevFeb 28, 2020
  6. Robert DaileyFeb 28, 2020
  7. Konstantin TokarevFeb 28, 2020
  8. Alex HenrieFeb 28, 2020

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.