Project

General

Profile

Documentation #20953

SubmittingPatches file describes backporting procedures inadequately

Added by Nathan Cutler over 2 years ago. Updated 6 months ago.

Status:
New
Priority:
Normal
Assignee:
Category:
-
Target version:
-
% Done:

0%

Tags:
Backport:
Reviewed:
Affected Versions:
Pull request ID:

Description

Needs a separate chapter, which should cover:

  • how to cherry-pick
  • Sam's three criteria for backport acceptance
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 - . . .
```

History

#1 Updated by Nathan Cutler over 2 years ago

  • Description updated (diff)

#2 Updated by Nathan Cutler 6 months ago

  • Description updated (diff)

Also available in: Atom PDF