Closed richardlau closed 2 years ago
+1 to swapping to squash/rebase merges only.
@canterberry, @nodejs/release any objections? If we're going to change the merge setting I'd like to do it before landing the open PRs.
+1 for changing to enabling "Squash and merge" and "Rebase and merge" and disabling "Create a merge commit".
A lot of folks prefer linear history because it produces a tidy list of changes over time, but squashing and rebasing can be problematic -- both practically and philosophically -- for a few reasons:
git blame
or similar on a line in a file to learn the why for how it came into its current state. Merge commits create a more readable history for this scenario than squashing.The current configuration was indeed a conscious decision, but that decision was made unilaterally by myself. Ultimately, I defer to @nodejs/release, of course, as the project owner and authority on the matter.
I'm in favor of being consistent with what we do across the project unless there is a specific version. Sounds like @canterberry it willing to go along with whatever @nodejs/releasers think is best.
I also think we should probably not block landing the PR that started this discussion as we want @RafaelGSS to be able to help with releases/security releases.
We discussed this in today's release wg meeting and decided to keep the merge commits for now and see how it goes.
I noticed that we only have "Merge pull request" enabled for this repository, which is the opposite of what we tend to have elsewhere where we don't allow "Merge pull request" in an attempt to have linear history (i.e. no merge commits). Maybe it doesn't matter, but let's make a conscious decision either way.
FWIW this is what our current history graph looks like: