3 ms·
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 thi
by hobarrera 10y ago
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 10y agoThe 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 10y agoThat 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.