Decide whether we want merge commits when a MR is merged
Gitlab has three configurable strategies for merging MRs:
Fast-forward with linear history. The commits are required to have been rebased on current master before merging (for outdated commits there is a Rebase button in the web UI which will do this for you, in simple cases where there are no conflicts), and are pushed as-is, without adding any details of the merge request. For example, this is how I merged !8 (merged): there is no indication in the commits that it was MR !8 (merged), or that David King reviewed it.
Merge commit with semi-linear history. The commits are required to have been rebased on current master, but then are merged with a non-trivial merge commit. For example, I enabled this before merging dbus-glib!1 (merged): you can see from the commit history that Alan Coopersmith contributed two commits dbus-glib@c22bbbe9 and dbus-glib@a1241eab, and when I clicked the Merge button, Gitlab created dbus-glib@73e32f5a for me.
Merge commit with non-linear history. I don't have a concrete example of this in dbus, but you can see it in https://gitlab.gnome.org/GNOME/glib if you examine the history of https://gitlab.gnome.org/GNOME/glib/merge_requests/389: you'll see that https://gitlab.gnome.org/GNOME/glib/commit/6c8b9f31b15bba38c7eb82b17437c1f462fb6ab8 merges a commit that is based on older-than-current code.
Unfortunately, these are chosen globally for a project (e.g. dbus/dbus), and maintainers can't choose which one is the most appropriate at the time they land a merge request.
The advantage of the linear history is that it's simple (one single line of ancestry in gitk/gitg), and very easy to use with
git bisect. The disadvantage is that we lose details of which merge request resulted in merging a particular change, which means it's harder to find the discussion that led to it being accepted.
The advantages of semi-linear history are that
git bisect still works well, and we still have details of the merge request.
The advantage of non-linear history is that the commit that gets merged is exactly what the patch submitter tested (although note that if we are concerned about this, we can always ask the patch submitter to rebase and re-test). The disadvantage is that bisecting won't necessarily work at all.
I think semi-linear history is a good compromise position, and I've enabled it in dbus and dbus-glib. Do any of the other maintainers agree or object?
Note that if we want to use a different strategy on a case-by-case basis, maintainers can bypass Gitlab and push directly to master. For stable branches, I'll probably stick to using
git cherry-pick from master and pushing directly to the stable branch.