Gerrit always rebase before submit patchset to avoid a merge commit - merge

Question

I found that when clicking "Submit Patch Set" in the Gerrit web interface, it'll either simply add a commit to that branch, or create a merge commit if another commit was submitted just before.
Example that creates 2 commit: The actual commit and a merge commit:
User submits patchset A depending on commit O
User submits patchset B depending on commit O
Submit Patch Set A
Submit Patch Set B --> Creates merge commit between O -> A and O -> B
There is a "Rebase Change" button which is great but it means that to submit a patch set everyone should always do:
Click Rebase Change
Click Submit Change Set
The only reason I see a merge commit useful is to keep dates of the commits (but I do understand why it is required without a rebase).
Isn't there an automatic rebase or at least a check to avoid generating an undesired merge commit?

Answer 1

Yes. Change the Submit Action for your project(s) to Cherry Pick. This will do roughly the same as rebasing when the submit button is pressed. It will keep the clean history you are looking for with no merge commits when submitting changes.

Answer 2

You can change the default submit type of the project by visiting the project settings page and choosing "Rebase if necessary" instead of "Merge if necessary".
For the complete documentation of Submit Types, see: https://gerrit-review.googlesource.com/Documentation/config-project-config.html#submit-type
The method Gerrit uses to submit a change to a project can be modified
by any project owner through the project console, Projects > List >
my/project. In general, a submitted change is only merged if all its
dependencies are also submitted, with exceptions documented below. The
following submit types are supported:
Inherit
This is the default for new projects, unless overridden by a global defaultSubmitType option.
Inherit the submit type from the parent project. In All-Projects, this is equivalent to Merge If Necessary.
Fast Forward Only
With this method Gerrit does not create merge commits on submitting a change. Merge commits may still be submitted, but they
must be created on the client prior to uploading to Gerrit for review.
To submit a change, the change must be a strict superset of the destination branch. That is, the change must already contain the tip
of the destination branch at submit time.
Merge If Necessary
If the change being submitted is a strict superset of the destination branch, then the branch is fast-forwarded to the change.
If not, then a merge commit is automatically created. This is
identical to the classical git merge behavior, or git merge --ff.
Always Merge
Always produce a merge commit, even if the change is a strict superset of the destination branch. This is identical to the behavior
of git merge --no-ff, and may be useful if the project needs to follow
submits with git log --first-parent.
Cherry Pick
Always cherry pick the patch set, ignoring the parent lineage and instead creating a brand new commit on top of the current branch head.
When cherry picking a change, Gerrit automatically appends onto the end of the commit message a short summary of the change’s
approvals, and a URL link back to the change on the web. The committer
header is also set to the submitter, while the author header retains
the original patch set author.
Note that Gerrit ignores dependencies between changes when using this submit type unless change.submitWholeTopic is enabled and
depending changes share the same topic. So generally submitters must
remember to submit changes in the right order when using this submit
type. If all you want is extra information in the commit message,
consider using the Rebase Always submit strategy.
Rebase If Necessary
If the change being submitted is a strict superset of the destination branch, then the branch is fast-forwarded to the change.
If not, then the change is automatically rebased and then the branch
is fast-forwarded to the change.
When Gerrit tries to do a merge, by default the merge will only succeed if there is no path conflict. A path conflict occurs when the
same file has also been changed on the other side of the merge.
Rebase Always
Basically, the same as Rebase If Necessary, but it creates a new patchset even if fast forward is possible AND like Cherry Pick it
ensures footers such as Change-Id, Reviewed-On, and others are present
in resulting commit that is merged.
Thus, Rebase Always can be considered similar to Cherry Pick, but with the important distinction that Rebase Always does not ignore
dependencies.