I was wondering if the community is willing to consider changing our style of commits and merges. The primary issue with the current system is that we cannot use git bisect
to isolate the source of a bug, and for a project as large and complex as a compiler, I feel that tool is an invaluable asset. As the codebase grows, it will only get harder to do RCA and fix the issues that crop up. I would like to know your opinions on two suggestions:
Ensuring that all commits in PRs are self-contained and atomic (no fixup/"merge main into branch" commits)
OR
Using the Squash and merge option for PRs and having separate PRs for changes in different parts of the codebase
Interesting idea. Not sure what i think about the conventional commit specification, but i definitely agree it is useful to have a clean trunk that is easy to understand and bisect. Though it is also important to make sure we keep it easy for new people to contribute to the Roc source code.
I think it is very useful to make sure every commit in trunk can build and pass tests if possible.
I am not sure the best way to do this with open source software that also isn't too much of a hassle for devs, new users, and reviewers. I like the idea of squashing as long as PRs are smallish. If we just switch to squashing and PRs are large, it actually will likely make bisecting worse due to just getting a gigantic diff that broke things somehow. But also, forcing smaller diffs means more reviews, more chunking of futures, more waiting on CI, and in general more hassle for devs. Not to mention GitHub has a very poor story for creating chains of PRs that are dependent on one another.
Not sure where that leaves us, but i do agree that it is definitely worth investigating more and investing in.
I think a good starting point would be to specify in CONTRIBUTING.md
that PRs should not have fixup commits. We can also include the git workflow to squash smaller commits into a single self-contained commit, so that new contributors don't find it daunting to make changes to a reviewed PR. If this is agreeable with everyone, I'll open a pull adding this!
I'd prefer to use a github ci workflow to prevent merging in fixup commits.
to squash smaller commits into a single self-contained commit, so that new contributors don't find it daunting to make changes to a reviewed PR.
Can you explain why more smaller commits would make it daunting to make changes?
Can you explain why more smaller commits would make it daunting to make changes?
I meant that newbies who are not familiar with git might not be aware of using git rebase -i
to squash fixup commits with the original commit. So listing out the steps they need to follow will allow them to fix review comments, rather than abandoning the PR out of the fear that they'll mess up the commit history.
I'd prefer to use a github ci workflow to prevent merging in fixup commits.
My bad, by "git workflow" I meant the sequence of git commands to squash multiple commits into one
I think there's been a slight mixup, my "I'd prefer to use a github ci workflow to prevent merging in fixup commits." was in response to " to specify in CONTRIBUTING.md that PRs should not have fixup commits".
I meant that newbies who are not familiar with git might not be aware of using git rebase -i to squash fixup commits with the original commit. So listing out the steps they need to follow will allow them to fix review comments, rather than abandoning the PR out of the fear that they'll mess up the commit history.
Perhaps we could "squash fixup commits with the original commit" automatically in a CI step.
so as I see it, the upsides and downsides of the conventional commit specification:
Upsides:
Downsides:
overall I definitely don't think that sounds like an improvement over the status quo of letting people write commit messages however they like :big_smile:
regarding bisecting, I use it all the time on the compiler (and have on other projects) and I haven't encountered merge commits being a problem :thinking:
the only problem is when a particular commit doesn't build
so given that we only merge PRs which pass CI, using squash and merge should make sure that all commits which make it into main
do indeed build
but like Brendan noted, this has the downside that now we lose commit granularity on main
, which makes it harder to track bugs down
I would rather keep the commit granularity and have to tell git bisect
to skip a commit once in awhile, so I don't think should adopt squash and merge
I do like the idea of giving guidance in CONTRIBUTING.md on making commits be buildable
although I don't think we should spend time enforcing it in PR review - just let people know we'd prefer that
from an enforcement perspective, it seems like the type of thing where it would be very easy to spend more time telling people they need to follow the rules than the amount of time the rules save us in debugging
so I think just letting people know, but not trying to enforce it, seems like the best way to save ourselves the most time overall!
Last updated: Jul 05 2025 at 12:14 UTC