
| 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@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