Documentation #20953
Updated by Nathan Cutler over 6 years ago
Needs a separate chapter, which should cover:
* how to cherry-pick
* Sam's three criteria for backport acceptance
<pre>
The purpose of the cherry-picked line is to communicate to future folks who might need to engage in forensic analysis when regressions occur, to track down what went wrong. Any information that those folks might find useful is a candidate for inclusion in the commit message.
If you simply (and manually) add `(cherry picked from . . .)` without further commentary, that would potentially deceive anyone looking at it, because they would be justified to conclude it was a clean, automated cherry-pick done the preferred way with `git cherry-pick -x`.
So, if the commit was not done in the preferred way, you would not manually edit the commit message to make it look like it was - instead, you could just append a brief statement, in your own words, explaining:
* why "git cherry-pick -x" could not be used
* how the bug was fixed in master
For the sake of those hypothetical future "forensic teams", would it be possible to run "git cherry-pick -x" in a throwaway branch, and copy the "cherry-picked from" and "Conflicts" lines over to this commit message? Then it would say at the bottom:
```
(manually cherry picked from . . .)
Conflicts:
file/foo/bar - . . .
file/baz/blat - . . .
```
</pre>