Stream: compiler development

Topic: Git squash and merge

Brendan Hansknecht (Oct 18 2023 at 22:21):

What's the general opinion of switching to squash and merge for PRs?

Recently have been messing with this more due to work and I think it has a few major benefits:

1. Main is essentially always healthy from a bisect perspective
2. It doesn't matter individual workflows (rebase, merge, many small commits, 1 giant commit). The final result on main is one unit without extra chaos. The longer a PR lives the more chaos it tends to contain (especially if people use merge to update it)
3. We just need to write one decent commit message to summarize that whole stack rather than caring about each individual commit.

Main downsides I can think of:

1. Lose the micro history. This means that when you bisect, it may be to a larger PR commit.
2. Roc looks like it is moving slower in terms of commit count (people like big numbers)

Richard Feldman (Oct 18 2023 at 23:27):

I don't care about downside #2 at all, but I do care about downside #1 for sure

Richard Feldman (Oct 18 2023 at 23:28):

when bisecting it's annoying to have to git bisect skip periodically, but if I get to "ok the problem is somewhere in this gigantic commit" that's way worse :sweat_smile:

Brendan Hansknecht (Oct 18 2023 at 23:30):

This may kinda be attributed to open sources vs company work. In company work, PRs tend to be reasonably sized (obviously, there are exceptions). In open source work, I think it is more often the case that people make large PRs and lump it all in one review.

Brendan Hansknecht (Oct 18 2023 at 23:32):

Like preferably most commits would be in the small 100s of lines range at max besides a few major ones that have to atomically update an api or similar.

Brendan Hansknecht (Oct 18 2023 at 23:32):

But that would likely mean making a lot more PRs for people who are contributing a lot and that may not fit Roc OSS workflow.

Brendan Hansknecht (Oct 18 2023 at 23:32):

Especially since github sucks at stacking PRs.

Richard Feldman (Oct 18 2023 at 23:38):

yeah I definitely appreciate that we benefit from resilience to suboptimal commit structure in overall valuable contributions :big_smile:

Anton (Oct 20 2023 at 08:21):

when bisecting it's annoying to have to git bisect skip periodically, but if I get to "ok the problem is somewhere in this gigantic commit" that's way worse :sweat_smile:

Yes, debugging is already very time consuming, let's not make it harder.

Brendan Hansknecht (Oct 20 2023 at 14:16):

I mean that's more a matter of commit size. I think having a tree of many broken commits is much worse than larger commits. But as mentioned above, smaller commits may not match open source as well

Brendan Hansknecht (Oct 20 2023 at 14:17):

The main reason I mentioned this is because at least at work, it makes things way cleaner and easier to debug

Elias Mulhall (Oct 20 2023 at 18:56):

My understanding of this workflow is that you bisect to find the PR that introduced the issue, then you dig up the corresponding branch and do another bisect within the branch. This of course requires holding on to old branches.

Last updated: Jul 26 2025 at 12:14 UTC