Gerrit always rebase before submit patchset to avoid a merge commit

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:

1. User submits patchset A depending on commit O
2. User submits patchset B depending on commit O
3. Submit Patch Set A
4. 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:

1. Click Rebase Change
2. 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?

Dither

This is not related to git config branch.autosetuprebase. – Dither

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.

Sarver

Great! I found it under Admin > Projects > MyProject > General > Project Options – Dither

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:

1. 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.

2. 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.

3. 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.

4. 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.

5. 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.

6. 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.

7. 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.

Radian