Best practices for merging?

Geoffrey Mainland mainland at
Sun Jan 31 18:10:42 UTC 2016

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
Is that what I should be doing?

For feature branches, is that also what is advised?


More information about the ghc-devs mailing list