Cherry-pick the upstream commit with the x option. Git appends a line naming the original commit to your commit message, so anyone can trace the backport. The line is added only when the pick has no conflicts, so for conflicted picks you must write the reference yourself.
Why the trail matters
A backported security fix is a promise: this code matches an upstream fix. Months later someone asks which advisory it answers and whether it still applies. Without a pointer to the source commit, the answer is archaeology. With one, it takes seconds.
The trail also helps the sync. When you later merge a newer upstream, a recorded source commit lets you see that the upstream version has replaced your backport, so you can drop your copy.
The command
git cherry-pick -x FIX_COMMIT
The Git documentation says the option appends a line reading "cherry picked from commit" followed by the original commit ID to the original commit message, to show where the change came from. It also states this is done only for cherry-picks without conflicts, and cautions against using the option when you are cherry-picking from your own private branch, since the hash is not useful to anyone else.
When there is a conflict
Backports to an older or modified base often conflict. After you resolve and commit, the source line is not added for you. Write it by hand in the message body:
Fix path traversal in archive extraction
Backport of upstream commit FULL_HASH
Advisory: ADVISORY_ID
Adapted: removed use of helper that does not exist in our base
The adapted line is the valuable part. It tells a future reviewer that the patch is not identical to upstream, so a patch equivalence check will not match it, and that a human should compare it with the upstream fix on the next sync.
A message template
| Line | Purpose |
|---|---|
| Summary under 70 characters | Searchable in the log |
| Backport of upstream commit, full hash | Links to the source |
| Advisory or issue ID | Links to the reason |
| Adapted: what you changed and why | Flags a non-identical patch |
| Remove when: condition | Says when the patch can go |
Query your backports later
Because the messages follow a pattern, you can list every backport with a log search on the message text. Feed that list into your fork notes or tracker. See carrying a patch while waiting for an upstream merge for the full lifecycle, and whether your fork contains an upstream security fix for checking that a backport counts.
Review the list at every sync. Each entry should end in one of three ways: kept with a reason, replaced by the upstream version, or dropped because the code is gone.
Where Safeguard fits
Safeguard's fix PRs, which are off by default and need your approval per category, show the same habit in the open: a reviewable change that says what it fixes. You can check what your build contains with a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. Notice how the fixed version and the finding it resolves are shown together.
Quick check
Does the x option always add the source line?
No. Git adds it only for cherry-picks without conflicts. After a conflict, write the reference in the message yourself.
Why add an adapted line?
It warns future reviewers that your patch differs from upstream, so they compare it by hand at the next sync.
Sources
Last reviewed: 19 October 2026.
