Best practices for merging?
ben at smart-cactus.org
Mon Feb 1 13:13:34 UTC 2016
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 472 bytes
Desc: not available
More information about the ghc-devs