# Squash when merging?
**URL:** https://racket.discourse.group/t/squash-when-merging/2105
**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:** 20
**Page:** 1
### Author:  [@jbclements](https://racket.discourse.group/u/jbclements)
#### Post date: [July 16, 2023, 10:39pm UTC](https://racket.discourse.group/t/squash-when-merging/2105/1 "2023-07-16T22:39:34Z")
Do we have a policy on whether to squash when merging a PR to the racket repo? My knee-jerk inclination is not to squash, it loses information, but I can see the case for squashing as well. Opinions?
Thanks!
John
---
### Author:  [@EmEf](https://racket.discourse.group/u/EmEf)
#### Post date: [July 17, 2023, 12:11am UTC](https://racket.discourse.group/t/squash-when-merging/2105/2 "2023-07-17T00:11:12Z")
Kind of. In the Style guide.
---
### Author:  [@gus-massa](https://racket.discourse.group/u/gus-massa)
#### Post date: [July 17, 2023, 1:26am UTC](https://racket.discourse.group/t/squash-when-merging/2105/3 "2023-07-17T01:26:16Z")
I most of the times squash before sending the PR.
For example implement something for` vector`s in a commit, then the same thing for `string`s in another, then for `byte`s. While adding the tests for bytes I get a brilliant idea and I add a few more test and I copy them for `vector`s and `string`s. In some case I separate the tests and then squash the new test with the old commits, n some cases it's a mess. Perhaps now refactor to use the same code for all of them. Or a new small feature for all of them. And now I have like 5 or 6 commits (and a few fixups). So I squash all of them before sending the PR.
In some cases it is possible to isolate the parts and I may choose to make two commits instead of a big one. (For example a new feature may expose an error in a signature of a function in Chez Scheme. I may fix the signature (+ tests) in a commit and add the feature (+ tests) in the second one.)
And also, there are the fixes and additions during the PR. Most of the time, I'll just squash them before merging. It makes the story easier to read in the future.
---
### Author:  [@hendrikboom3](https://racket.discourse.group/u/hendrikboom3)
#### Post date: [July 17, 2023, 2:20am UTC](https://racket.discourse.group/t/squash-when-merging/2105/4 "2023-07-17T02:20:49Z")
What does 'squash' mean in this context?
-- hendrik
---
### Author:  [@jbclements](https://racket.discourse.group/u/jbclements)
#### Post date: [July 17, 2023, 4:51am UTC](https://racket.discourse.group/t/squash-when-merging/2105/5 "2023-07-17T04:51:41Z")
Section 8, " [Retiquette: Branch and Commit](https://docs.racket-lang.org/style/branch-and-commit.html) ? Not seeing anything there about squashing or not squashing? I should clarify, this is in re: merging PRs submitted by someone else. (And I'm not thinking of a particular case, just wondering in general.) I suppose "use your judgment" is pretty reasonable here.
---
### Author:  [@jbclements](https://racket.discourse.group/u/jbclements)
#### Post date: [July 17, 2023, 4:54am UTC](https://racket.discourse.group/t/squash-when-merging/2105/6 "2023-07-17T04:54:20Z")
When submitting to a git repo, a "squash" refers to the act of collapsing a sequence of adjacent commits into one commit. There is support in the command-line tools and in helper tools such as github for squashing a number of commits when making a PR. In some projects, this is considered de rigueur; every PR should be exactly one commit. It sounds like we don't have hard-and-fast rules about this.
---
### Author:  [@jryans](https://racket.discourse.group/u/jryans)
#### Post date: [July 17, 2023, 9:42am UTC](https://racket.discourse.group/t/squash-when-merging/2105/7 "2023-07-17T09:42:48Z")
My understanding from the style guide and observing behaviours in the [GitHub - racket/racket: The Racket repository](https://github.com/racket/racket) repo is that meaningful, independent commits with useful commit messages are preferred. Merge commits should be avoided. (Other repos may have different policies.)
So, when merging someone else's PR, you have two remaining options (since merge commits are out): squash or rebase. In my experience, it's usually clear enough which to choose when skimming the list of commits: if they appear to be independent useful chunks of work with good messages, use rebase to preserve them, otherwise squash.
Sometimes people (out in the wider world, I don't see it much in the Racket community) commit very frequently with low signal messages. In cases like that, it's best to squash for sure, as those commits are really just WIP milestones for the author which are unlikely to make sense to others.
---
### Author:  [@spdegabrielle](https://racket.discourse.group/u/spdegabrielle)
#### Post date: [July 17, 2023, 10:04am UTC](https://racket.discourse.group/t/squash-when-merging/2105/8 "2023-07-17T10:04:51Z")
I think Iβm guilty of this sometimes.
This looks like a helpful post:
> **[Squash your commits | The GitHub Blog](https://github.blog/2016-04-01-squash-your-commits/)**
>
> Gitβs flexibility allows you to shape your workflow however you like. The organization of your git history is just one of the choices to make, but up until now the merge button on GitHub only created merge commits, resulting in a style of history...
S.
---
### Author:  [@jbclements](https://racket.discourse.group/u/jbclements)
#### Post date: [July 17, 2023, 8:27pm UTC](https://racket.discourse.group/t/squash-when-merging/2105/9 "2023-07-17T20:27:33Z")
That blog post looks over-simplified and kind of almost-wrong. Specifically, in my opinion the author really should have used an example where work continued on the main branch before the merge/rebase. I would also say that merge/rebase is almost entirely independent of squashing, I don't see what the interaction is. But ... okay?
---
### Author:  [@spdegabrielle](https://racket.discourse.group/u/spdegabrielle)
#### Post date: [July 17, 2023, 8:34pm UTC](https://racket.discourse.group/t/squash-when-merging/2105/10 "2023-07-17T20:34:59Z")
I must have misread. It is also a 2016 post and the GitHub ui has changed dramatically. Regardless: I.Must. Squash. π
Edit: current docs [About pull request merges - GitHub Docs](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/about-pull-request-merges#squash-and-merge-your-commits)
---
### Author:  [@mflatt](https://racket.discourse.group/u/mflatt)
#### Post date: [July 18, 2023, 1:05pm UTC](https://racket.discourse.group/t/squash-when-merging/2105/11 "2023-07-18T13:05:11Z")
> [@jbclements](#):
>
> Do we have a policy on whether to squash when merging a PR to the racket repo? My knee-jerk inclination is not to squash, it loses information, but I can see the case for squashing as well. Opinions?
I think PRs normally should be squashed, because they normally correspond to one coherent change. 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).
Not wanting to lose information makes sense, but this extra information gets in the way. In fact, I'm motivated to reply because I was trying to get my bearings on recent commits, and the non-squashed merge made that a little harder. π
---
### Author:  [@sorawee](https://racket.discourse.group/u/sorawee)
#### Post date: [July 18, 2023, 1:20pm UTC](https://racket.discourse.group/t/squash-when-merging/2105/12 "2023-07-18T13:20:32Z")
Sorry for the mess! I did intend to squash it.
---
### Author:  [@greghendershott](https://racket.discourse.group/u/greghendershott)
#### Post date: [July 18, 2023, 3:53pm UTC](https://racket.discourse.group/t/squash-when-merging/2105/13 "2023-07-18T15:53:13Z")
> [@mflatt](#):
>
> I imagine the PR author expected squashing in in this case (maybe because I almost always squash when merging).
That's been my assumption/expectation in the (relatively few) PRs I've made.
In fact my impression of the de facto policy is, "JIT squash".
1. While the PR has any ongoing conversation ("please change X") then I just push more commits with the requested changes. I figure that detailed history might be easier to follow, during review? So I wouldn't want to squash too soon.
2. When things settle down, I _might_ force-push a squash. But normally I'd leave that up to the merger. I figure it's their repo, and really up to them how they prefer the history for their main branch?
---
### Author:  [@jbclements](https://racket.discourse.group/u/jbclements)
#### Post date: [July 18, 2023, 4:49pm UTC](https://racket.discourse.group/t/squash-when-merging/2105/14 "2023-07-18T16:49:32Z")
Okay, I think I hear a consensus preference for squashing, many thanks.
Side note: I can't tell whether this is genuine curiosity or the desire to find errors in others' statements, apologies if it's the latter, but @greghendershott you also appear to be suggesting that the two choices are (squash-and-rebase) and (dont-squash-and-merge). Is there some reason that (dont-squash-and-rebase) isn't an option? Let me reiterate that I do think that I see a clear preference for squash-and-rebase here, I just feel like I'm missing something.
---
### Author:  [@jbclements](https://racket.discourse.group/u/jbclements)
#### Post date: [July 18, 2023, 4:54pm UTC](https://racket.discourse.group/t/squash-when-merging/2105/15 "2023-07-18T16:54:03Z")
Oh! I think I'm starting to see the issue here, it's a GitHub interface choice?
IOW, GitHub doesn't give you squash-and-rebase. That's weird to me. In fact, they say "Rebase and Merge", which is more or less a direct contradiction, using those terms in what I'm going to snootily call the classic git sense.
---
### Author:  [@greghendershott](https://racket.discourse.group/u/greghendershott)
#### Post date: [July 18, 2023, 5:13pm UTC](https://racket.discourse.group/t/squash-when-merging/2105/16 "2023-07-18T17:13:42Z")
["Squash and merge" attempts a _fast-forward merge_](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/about-pull-request-merges#squash-and-merge-your-commits) -- which will fail if there is a merge conflict.
IIRC, if the branch needs to be rebased (to enable doing a fast-forward merge), the GitHub UI will have already warned about that, and offered a button to click to attempt the rebase.
---
### Author:  [@jbclements](https://racket.discourse.group/u/jbclements)
#### Post date: [July 18, 2023, 5:25pm UTC](https://racket.discourse.group/t/squash-when-merging/2105/17 "2023-07-18T17:25:36Z")
Oog. Sounds to me like GitHub is just making up terms here. When they say "fast-forward commit", I think they're saying "a rebase with no conflicts". That's just not a merge. Specifically, a merge commit is one with two antecedents. I see no reason for them to muddy the waters by using the term "merge" for something else. Bleah.
---
### Author:  [@greghendershott](https://racket.discourse.group/u/greghendershott)
#### Post date: [July 18, 2023, 5:33pm UTC](https://racket.discourse.group/t/squash-when-merging/2105/18 "2023-07-18T17:33:08Z")
Derp. Not their fault, mine. I meant to write "fast-forward merge".
And "fast-forward merge" is [git's term](https://git-scm.com/docs/git-merge#_fast_forward_merge).
TL;DR: Although GitHub may deserve blame for many things, this isn't one. π
---
### Author:  [@shhyou](https://racket.discourse.group/u/shhyou)
#### Post date: [July 18, 2023, 5:33pm UTC](https://racket.discourse.group/t/squash-when-merging/2105/19 "2023-07-18T17:33:41Z")
Squashing commits already grows a new commit containing all the changes in the PR, so there is no need to modify the original commits in the PR. Rebase and merge re-grows all existing commits in the PR to concatenate them on top of the main branch. The typical merge-commit-strategy is disabled as indicated in the top-most option.
---
### Author:  [@jbclements](https://racket.discourse.group/u/jbclements)
#### Post date: [July 18, 2023, 5:55pm UTC](https://racket.discourse.group/t/squash-when-merging/2105/20 "2023-07-18T17:55:33Z")
Right, but you could certainly squash and then have a non-trivial merge commit, and I can even imagine this being a sensible choice for some workflows.
I can see (in my own head) that this is gradually shading over from "what's the right thing to do" to "I need to prove that I'm right", so ... I'm happy to let this go.
Oh, wait, I know what I'm supposed to say here:
"Hmpf" π
[Next page](https://racket.discourse.group/t/squash-when-merging/2105.md?page=2)