# Squash when merging? **URL:** \ **Category:** Internals\ **Created:** [July 16, 2023, 10:39pm UTC](https://racket.discourse.group/t/squash-when-merging/2105 "2023-07-16T22:39:34Z")\ **Posts on this page:** 3\ **Page:** 2
**Author:** ![robby](https://yyz2.discourse-cdn.com/free1/user_avatar/racket.discourse.group/robby/32/7_2.png) [@robby](https://racket.discourse.group/u/robby)\ **Post date:** [July 19, 2023, 2:36am UTC](https://racket.discourse.group/t/squash-when-merging/2105/21 "2023-07-19T02:36:49Z")
My $0.02: I am in agreement with what @jryans , @gus-massa and @mflatt write about how commits should look and @greghendershott 's "JIT squash" comment but I wanted to add a comment about a rationale (which is implicit in @mflatt 's message). I think that our goal with the history that appears on the main/master branch should be that it is the most helpful it can be to some future programmer who is looking backwards trying to track down some bug (or otherwise understand the current state of the codebase). In that sense, a linearly ordered sequence of individually meaningful commits is the most helpful and so that's probably how the current (implicit) policy came to be. It seems to me, based on this conversation, that this policy and the rationale for it aren't obvious to folks (especially given that other projects do other things) so the policy and the rationale seem like a good candidate for Style Guide inclusion (perhaps via an addition to [this section](https://docs.racket-lang.org/style/branch-and-commit.html#%28part._.Commit%29) or a nearby revision somehow). ---
**Author:** ![LiberalArtist](https://yyz2.discourse-cdn.com/free1/user_avatar/racket.discourse.group/liberalartist/32/151_2.png) [@LiberalArtist](https://racket.discourse.group/u/LiberalArtist)\ **Post date:** [July 19, 2023, 1:24pm UTC](https://racket.discourse.group/t/squash-when-merging/2105/22 "2023-07-19T13:24:48Z")
I agree with everything in this thread, I think. > [@mflatt](#): > > There are sometimes larger PRs where keeping the commits makes sense, but that's not the usual case. > > I can see why you'd ask, because PR #4676 is a good example where squashing is better. The commit messages in that case make sense as part of a PR revision process, but not as a part of the Racket source history. I imagine the PR author expected squashing in in this case (maybe because I almost always squash when merging). A recent example that I am glad was _not_ squashed when merging is [Add `#:indent` to `write-json` [reprise] by LiberalArtist · Pull Request #4686 · racket/racket · GitHub](https://github.com/racket/racket/pull/4686), which consisted of four commits: 1. [[json]: Add `#:indent` to `write-json`. · racket/racket@92ba659 · GitHub](https://github.com/racket/racket/commit/92ba65972547e020ceca8115bbb19a4caa039a9d) 2. [json: add tests for `#:indent` · racket/racket@d10c2fc · GitHub](https://github.com/racket/racket/commit/d10c2fc1e5e7cb3de1d2ff89e9820cc5147ac095) 3. [json: fixup indentation of objects · racket/racket@6f8824d · GitHub](https://github.com/racket/racket/commit/6f8824d4f360ba6d2fda5f5e063a5279661d0aa3) 4. [json: remove `#:indent` test datum 2155a30 · racket/racket@7e9b9c6 · GitHub](https://github.com/racket/racket/commit/7e9b9c6759c1bcb7d205f3e1e83684076afe68c6) The first commit was written a year before the rest and by a different author. (I did squash the 11 commits from [the earlier PR](https://github.com/racket/racket/pull/4300) when picking it up.) I'm especially glad the third commit was not squashed because there was a lot of discussion in the earlier PR and at [Json Beautifier - #2 by LiberalArtist](https://racket.discourse.group/t/json-beautifier/1541/2) about exactly what behavior the `#:indent` option should implement. I imagined it could have been horribly confusing to the future bug-hunter not to note in the history the subtle change from the almost-correct behavior. The last commit was a more marginal case, but the underlying problem confused me enough to err on the side of being explicit. ---
**Author:** ![benknoble](https://yyz2.discourse-cdn.com/free1/user_avatar/racket.discourse.group/benknoble/32/16_2.png) [@benknoble](https://racket.discourse.group/u/benknoble)\ **Post date:** [July 21, 2023, 1:25pm UTC](https://racket.discourse.group/t/squash-when-merging/2105/23 "2023-07-21T13:25:10Z")
(Replying to this message because it seemed the most relevant, but really these are just some free-form thoughts.) I really like the way the Git community works with people who submit patches: they give feedback not just on the code, but on the structure of the patch series (analogous to a PR). If a commit message needs work of if a commit should be split, squashed, etc., that becomes part of review. It's expected that you resubmit several times (if necessary) to incorporate appropriate feedback. On GitHub, you would do this by rebasing (`--interactive`ly, if needed) and force-pushing to your PR. Fortunately, the same community is usually pretty willing to explain how to accomplish these things, or at least point you to the docs and help you figure out what you need to do. On the maintainer side, this is maybe more upfront work per PR. The end result is more satisfying in terms of valuable information in each commit. It also doesn't deny you the choice of rebase-and-fast-forward or merge, once the PR is ready. In extremely trivial cases, I could also see the following flow: a maintainer fetches the PR, does some minor editing (`--amend`, etc.) and pushes, closing the PR (but the original author retains credit, thanks to the difference between author and committer). Then, the maintainer comments on the PR explaining what they changed, why, and how. This eases the burden of initial, small contributions but teaches "how to fish" for next time. [Previous page](https://racket.discourse.group/t/squash-when-merging/2105.md?page=1)