Affected Version:
Up to latest (2.11)
What steps will reproduce the problem?
Access documentation: https://gerrit-documentation.storage.googleapis.com/Documentation/2.11/user-changeid.html#cherry-pick
It reads:
"When cherry-picking a commit, leave the Change-Id line alone to have Gerrit treat the cherry-picked commit as a replacement for the existing change. This can be very useful if the project has a fast-forward-only merge policy, and the submitter is downloading and cherry-picking individual changes prior to submission, such as by gerrit-cherry-pick.
Or, you may wish to delete the Change-Id line and force a new Change-Id to be generated automatically, thus creating an entirely new change record for review. This may be useful when backporting a change from the current development branch to a maintenance release branch."
However, Gerrit actually tracks commits using the (ChangeID, branch) tuple, so a cherry-pick to a different branch will NOT replace an existing change and pickup the original change's review history. It will in fact create an entirely new change record for review, as described in the second paragraph.
Furthermore, keeping the ChangeID is useful as it permits easier tracking of cherry-picks across branches, especially when users don't use the obscure "-x" option to "git cherry-pick"
What is the expected output? What do you see instead?
Suggested rewriting:
"Gerrit uses the (ChangeID, branch) pair to identify commits across changes. Thus, a cherry-pick to a new branch, even with the same ChangeID, is identified as a different change and will create an entirely new change record for review. This was incorrectly documented in previous versions of Gerrit.
You should keep the original ChangeID in order to facilitate tracking of cherry-picks across branches.
There is no method to tie a cherry-pick's review to the original commit's review."