Migration PEP: https://www.python.org/dev/peps/pep-0512/

hobarrera · on Feb 10, 2017

The PEP mentions that they'll be using a linear git history (no merges), but doesn't explain any of the reasons or perceived advantages of doing so. I found this pretty curious because (1) PEPs tend to explain why a decision is made, much like an RFC would (2) it's the really odd choice to make.

progval · on Feb 11, 2017

The important part is not for it to be linear, it's to have each PR squashed. Linearity is just a consequence:

> People preferred having a single commit representing a single change instead of having a set of unrelated commits lead to a merge commit that represented a single change.

hobarrera · on Feb 20, 2017

That justifies squashing inside a PR, but not making it linear. Commits might be coherently separated, eg:

Commit 1: Add a user model Commit 2: Add migrations for user model Commit 3: Implement endpoints for users

Squashing them is pointless, and mixing them into a linear history really adds no value.

I do agree with squashing commits than cancel each other out inside a branch.