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:
Main downsides I can think of:
I don't care about downside #2 at all, but I do care about downside #1 for sure
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:
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.
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.
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.
Especially since github sucks at stacking PRs.
yeah I definitely appreciate that we benefit from resilience to suboptimal commit structure in overall valuable contributions :big_smile:
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.
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
The main reason I mentioned this is because at least at work, it makes things way cleaner and easier to debug
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 06 2025 at 12:14 UTC