Best practices for merging?

[Ben Gamari]

Simon Peyton Jones <simonpj at microsoft.com> 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160201/53c771ad/attachment.sig>