Simon Peyton Jones <[email protected]> writes: > I'm no git expert here, but > > * Feature branches typically have lots of intermediate fixups. > We don’t want that sequence in the main history; it's like > watching sausage being made, and many intermediate points may > be broken. Better to have one big, coherent commit. > > * If a feature branch really has several independent pieces, then > yes, it'd be better to make several commits. Perhaps Phab doesn't > support this well. In that case, would it make sense to make > each into a separate Phab ticket? > > * I have no idea what an "empty merge commit" is, or why it might > be better that "a commit". > > After all, a fast-forward commit is no different to cloning, doing > a very quick job on the feature, and committing. > If there are multiple commits then a merge commit can serve to logically group them. 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 the 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 this, in
part due to Phab's poor support for fine-grained changes.
Cheers,
- Ben
signature.asc
Description: PGP signature
_______________________________________________ ghc-devs mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
