Squash merging

[Turbo87]

I noticed that in this project we use squash merging by default and regular merges are actually disabled in the GitHub UI. Is there a reason for that?

I personally prefer regular merge commits since it makes usage of git bisect much easier. For PR with only a single commit I prefer squash merging too, but when multiple commits are involved squash merging feels like losing history/context to me. When the PR author is not keen on commit hygiene squash merging might still make sense, but in my experience merge commits would be a better default.

/cc @jplatte

[jplatte]

Main reason is David Pedersen always did it that way. I'm personally not a big fan of merge commits though I can see their value.

In other projects I maintain I switch between squash and rebase (or fast-forward via commandline) merges depending on whether the history is clean. Would you see that as an improvement? That should be better for bisecting while avoiding the downsides of merge commits (primarily around non-linear history that's just harder to work with, but I also sometimes find it annoying to have the history littered with low-signal merge commits).

[jplatte]

You also didn't need to ping me here 😉
I saw but wanted to review PRs before writing my answer here (that I expected to be even longer, but decided to cut short and wait for your reply).

[Turbo87]

You also didn't need to ping me here 😉

ah, good to know. wasn't sure whether you were monitoring the Discussions too :D

my main issue with rebase merging is that it causes the git history to now contain any references to the pull request, which makes it harder to lookup any related PR discussions for a commit.

I somewhat agree on the non-linear merge history and I'm not a big fan of having dozens of parallel lines in my history viewer either, but I usually solve this by regularly rebasing PRs before they get merged.

[ttys3]

If the submission itself is a very large change, I think it is better to keep a good history record before merging it. However, this also requires the submitter to organize or rebase their changes locally so that the history remains as clean as possible after merging. For example, during the PR process, modifications for the same small feature might be spread across three commits: a, b, and f. In this case, before merging, the submitter should use interactive rebase locally to combine these three commits into one and then force push. Otherwise, the resulting merged code might not be as conducive to troubleshooting and readability.

On the contrary, if the changes in the PR itself are very small, I think squash is a very good choice.