Consider disabling merge commits, requiring squash (and maybe rebase) only

[agoode]

https://github.com/openslide/openslide/settings

Merge commits add a new commit without content and can clutter history. Squash commits convert an entire pull request into a single commit, keeping minor changes made during review time out of the committed history.

It is a personal preference how this is configured, but I have found squash commits to work better than other styles when using code review.

Rebase commits are a little better than merge commits, but still can generate extra commit history.

[bgilbert]

The advantage to merge commits is that they preserve the development history. When a change evolves due to review comments, I'd generally prefer to have that history maintained in the repo, rather than obscuring the reason that things were done a particular way. The exception is very messy PRs, in which case some sort of history rewriting may make sense. My approach at the moment is to ask submitters to rewrite and force-push when needed for e.g. formatting changes, and otherwise to preserve history.

Rebase commits preserve messy history, for good and for ill, but obscure the fact that the changes were developed and tested against a different base commit than the one they were merged against. This seems suboptimal.

[agoode]

The other benefit of squash commits is that it makes bisecting easier, both automatically and manually.

I am ok with either way, but when we decide, we should update/rewrite CONTRIBUTING.txt (as .md maybe) and document the process there.