Use rebases instead of merge commits

.github/mergify.yml

@@ -19,10 +19,14 @@ pull_request_rules:
   - actions:
       queue:
         name: default
-        # Merge into master with a merge commit
-        method: merge
-        # Update the pr branch with rebase, so the history is clean
-        update_method: rebase
+        # Merge into master with a rebase
+        # NB. must use "squash" here so the squash commit contains the PR
+        # number fr changelog-d. If you really need it to not be squashed,
+        # use merge+no rebase.
+        method: squash
+        # both update methods get absorbed by the squash, so we use the most
+        # reliable
+        update_method: merge
     name: Put pull requests in the rebase+merge queue
     conditions:
       - base=master
@@ -60,8 +64,8 @@ pull_request_rules:
   - actions:
       queue:
         name: default
-        # Merge with a merge commit
-        method: merge
+        # Merge with a rebase
+        method: rebase
         # Update the pr branch with rebase, so the history is clean
         update_method: rebase
     name: Put backports in the rebase+merge queue

CONTRIBUTING.md

@@ -283,9 +283,9 @@ Currently there is a 2 day buffer for potential extra feedback between the last
 update of a pull request (e.g. a commit, a rebase, an addition of the `merge me`
 label) and the moment the Mergify bot picks up the pull request for a merge.
 
-If your pull request consists of several commits, consider using `squash+merge
-me` instead of `merge me`: the Mergify bot will squash all the commits into one
-and concatenate the commit messages of the commits before merging.
+Currently `merge me` and `squash+merge me` do the same thing. If you need to
+preserve the individual commits, you must use `merge+no rebase` (see below).
+Please rebase manually beforehand, if you can.
 
 There is also a `merge+no rebase` label. Use this very sparingly, as not rebasing
 severely complicates Git history. It is intended for special circumstances, as when