I was recently made aware that Gerrit now supports adding metadata to commit messages in the "rebase" strategy. The "cherry-pick" strategy that we're using has been chosen over everything else primarily due to this capability.

Some details:

Gerrit supports different ways of committing changes into branches when developers submit them, with different effects on which changes are considered ready and how they show up in the commit history.

The two main contenders are "cherry-pick" and "rebase always".

Both create a linear history (unlike some "merge" strategies that can create merge commits.

Both add metadata to the commits, all that "Reviewed-on", "Reviewed-by" etc in the commit message.

Cherry-pick considers every change on Gerrit on its own. Even if you push a patch train of 50 commits, it allows submitting commit #49 individually. That gives some flexibility (if these commits are truly independent) but also creates risk: if changes are merged out of order, we might break the tree with otherwise perfectly good commits, for example when a new API is used that is only added by a previous commit.

Rebase always considers patch trains: To submit commit #49, the commit itself and all its 48 ancestors need to be ready for submission. It becomes a one-click operation in the UI and ordering is honored. On the other hand, picking an individual commit is a manual operation now (cherry-pick to become its own patch train, push, re-review).
--