Best practices for merging?
Simon Peyton Jones
simonpj at microsoft.com
Mon Feb 1 17:11:01 UTC 2016
| Squashing large change sets into a single patch is also undesirable---
| it makes figuring out exactly what changed more difficult and makes
| bisecting less useful.
My personal preference is:
* Always squash the "sausage-being-made" commits of a feature branch.
The sometimes-torturous history is not of interest to later readers.
* If a feature-branch-author is willing to take the time to break the
feature into a bunch of related sub-feature, each with its own, documented,
self-contained commit -- then excellent!
* Avoid non-empty merge commits.
* I'm agnostic about the empty-merge-commit thing, but now I can see the
logic and am fine with having them.
The guiding principle is: keep information that is valuable in later years;
discard noise that will simply be distracting in later years.
But like Geoff I'm not trying to impose anything, since I regard myself
as a git amateur.
I'd love someone to write down the result of this
conversation in our working conventions.
| Again, I'm not trying to impose a workflow---I just wasn't sure if
| there was a new recommended workflow.
| >> For instance, in the case of Geoff's recent fix,
| >> $ git log --graph --oneline origin/master
| >> * e5a0a89 Suppress substitution assertions to fix tests
| >> * a883c1b Missing @since annotations in GHC.Generics
| >> * f8e2b7e Minor doc fixes to GHC.Generics
| >> * 34519f0 When encountering a duplicate symbol, show source of
| >> first symbol * 669cbef Fix Trac issue #11487.
| >> |\
| >> | * 6544f8d Properly track live registers when saving the CCCS.
| >> | * 90f688e Code formatting cleanup.
| >> | * 4d0e4fe Add type signatures.
| >> |/
| >> * b61f5f7 Put docs in /usr/share/doc/ghc-<version>
| >> Here we see that those three commits were developed on a feature
| >> branch, which was then merged into master in 669cbef.
| >> For what it's worth I quite like this practice. That being said, in
| >> GHC we rarely have changes broken up into multiple commits like
| >> in part due to Phab's poor support for fine-grained changes.
| >> Cheers,
| >> - Ben
| ghc-devs mailing list
| ghc-devs at haskell.org
More information about the ghc-devs