Simon Peyton Jones
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