Best practices for merging?

[Simon Peyton Jones]

|  Squashing large change sets into a single patch is also undesirable---
|  it makes figuring out exactly what changed more difficult and makes
|  bisecting less useful.

My personal preference is:

* Always squash the "sausage-being-made" commits of a feature branch.
  The sometimes-torturous history is not of interest to later readers.

* If a feature-branch-author is willing to take the time to break the
  feature into a bunch of related sub-feature, each with its own, documented,
  self-contained commit -- then excellent!

* Avoid non-empty merge commits.

* I'm agnostic about the empty-merge-commit thing, but now I can see the 
  logic and am fine with having them.

The guiding principle is: keep information that is valuable in later years;
discard noise that will simply be distracting in later years.


But like Geoff I'm not trying to impose anything, since I regard myself 
as a git amateur.

I'd love someone to write down the result of this 
conversation in our working conventions.

Simon

|  
|  Again, I'm not trying to impose a workflow---I just wasn't sure if
|  there was a new recommended workflow.
|  
|  Cheers,
|  Geoff
|  
|  >> 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
|  >
|  
|  
|  _______________________________________________
|  ghc-devs mailing list
|  ghc-devs at haskell.org
|  https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.ha
|  skell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
|  devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c41dd179c03104456
|  6c7608d32b1be29a%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Y%2buUjGT
|  9llfuw4mmRZA3TdL%2fmAKhx2pL3954UZN6Y5c%3d