Best practices for merging?

[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.

What am I missing?

Simon

| -----Original Message-----
| From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Geoffrey
| Mainland
| Sent: 31 January 2016 18:11
| To: ghc-devs at haskell.org Devs <ghc-devs at haskell.org>
| Subject: Best practices for merging?
| 
| I've been away from GHC for a while, and it's not clear to me what the
| best practices for merging are now.
| 
| My usual git workflow is to work on a feature branch, get a nice clean
| set of patches, each of which implements a discrete bit of
| functionality, rebase onto master, and then merge with an empty merge
| commit, i..e, *not* fast-forward. This lets me look at the repo history
| and easily see where a feature branch landed and get a good idea of what
| changes it contains. I have used this approach in the past with GHC,
| e.g., SIMD support and typed TH.
| 
| For smaller sets of changes, I might skip the merge commit, but I still
| break up my changes into discreet bits, which helps anyone reading the
| change set to see what's going on.
| 
| It seems the current policy is to submit changes via Phab and then,
| after approval, squash everything into a single patch and apply it with
| arc. At least that is my reading of
| https://ghc.haskell.org/trac/ghc/wiki/Phabricator/Extras#Landingreviews.
| Is that what I should be doing?
| 
| For feature branches, is that also what is advised?
| 
| Thanks,
| Geoff
| 
| _______________________________________________
| ghc-devs mailing list
| ghc-devs at haskell.org
| https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haskell.
| org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
| devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c0b2671ff9bed4a35ddd108
| d32a69d7a9%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=XIbsIBRwd3bLRha9OjVxw
| jdyEas6qnTNnciHvjCyC9E%3d