What does the -x option add when you run git cherry-pick?
answer
- it changes the message, not the change
- answers "where did this come from"
- records an id in the copy
- typical on maintenance-branch backports
- useless when the source is private
basics
~20 sgit cherry-pick -x appends a line to the copied commit's message recording the id of the commit it came from, in the form (cherry picked from commit <sha>). It documents provenance; it changes nothing about the content applied.
solid answer
~40 sBy default a cherry-picked commit reuses the original message with no indication that it is a copy, so on a release branch you cannot tell whether a fix originated there or was backported. `-x` appends `(cherry picked from commit <sha>)` to the message, naming the source commit. That is purely documentation — the diff, author and everything else are unchanged — but it is what lets a maintainer later ask "where did this come from" and follow the trail back to the main-line commit. It is the convention for backports onto maintenance branches. The Git documentation cautions against `-x` when picking from a **private** branch, because the recorded id points at a commit nobody else can look up, making the line noise.
code
console · 5 lines$ git cherry-pick -x 9f2a1c3
$ git log -1 --format=%B
fix null deref in session lookup
(cherry picked from commit 9f2a1c3d4e5f60718293a4b5c6d7e8f901234567)go deeper
Recall that this option only appends a line naming the original commit; the change applied is exactly the same either way.
Explain why the default copy is indistinguishable from an original commit, and what the recorded id lets a later reader do.
Argue for it as a maintenance-branch convention and describe how you audit which fixes have been backported when release branches diverge.
Decide the provenance standard across long-lived branches — how backports are recorded, audited, and kept honest as release lines multiply.
## The provenance problem Cherry-picking copies a change: a new commit, a new SHA, same message and author. Six months later, looking at a release branch, you see a commit titled "fix null deref in session lookup". Was it written on this branch, or backported from the main line? Nothing in the default output says. If it was backported, you would like to know **which** commit it came from — to see the review discussion around it, to check whether follow-up fixes to the same code also need backporting, or to confirm the two branches carry the same fix. `-x` answers that by writing the source id into the copy's message. ## Exactly what it does With `-x`, the message of the new commit gets an appended line: (cherry picked from commit 9f2a1c3d4e5f60718293a4b5c6d7e8f901234567) That is the whole feature. It does not change the diff, the author, the tree, or anything Git does with the commit — it is metadata for humans and for tooling that greps messages. Because it lives in the message body, it survives being read by anyone with the repository, and it is greppable: `git log --grep="cherry picked from commit 9f2a1c3"` finds every branch that carries the backport. ## When to use it and when not to Use it whenever the copy will outlive the moment: - backporting fixes onto release or maintenance branches, where a maintainer will audit later what has and has not been carried across; - copying a change into a long-lived branch that many people read. The documented caution is against using it when picking from a **private or local** branch: the recorded SHA names a commit that nobody else can resolve, so the line is meaningless to every future reader and slightly misleading, since it looks like it should be lookupable. Also worth noting: `-x` does not make the branches related in Git's eyes. Ancestry is unchanged, so no merge, log or reachability query treats the copy as the original. It is a note, not a link. ## Neighbouring options The other message-affecting options on the same command are worth keeping straight: - `-e` / `--edit` — open the message in an editor before committing. - `-s` / `--signoff` — add a `Signed-off-by` trailer for the person doing the pick. - `-n` / `--no-commit` — apply to the working tree and index and stop, so you write the message yourself; combining `-n` with several picks and one manual commit means no `-x` line is generated at all, so record provenance by hand if you need it. ## The habit around it Projects that maintain release branches usually make `-x` mandatory for backports, so every maintenance-branch commit that came from elsewhere says so. The payoff shows up when a follow-up bug appears in the backported code: the recorded id takes you straight to the original commit and everything around it, instead of a text search for a similar-looking diff. A final caution: the line is only as accurate as the moment it was written. If the source commit is later rewritten — the branch it lived on rebased, for example — the recorded id can point at a commit that no longer exists on any branch, though the object may still be reachable. That is an argument for cherry-picking from stable, published history, which is the same branch the option is recommended for in the first place.
- Why does the Git documentation discourage -x when cherry-picking from a private branch?The appended line names a commit id that nobody else can resolve, since the source commit exists only in your local clone. Future readers see what looks like a lookupable reference and cannot follow it. The option is aimed at copies from published branches, where the recorded id is meaningful to everyone.
- Does -x create any relationship Git itself understands between the two commits?No. It writes a line into the commit message and nothing more. Ancestry is unchanged, so merges, `git log` reachability and every other query still treat the two commits as unrelated objects that happen to carry the same diff. Any tooling that uses the line works by parsing message text.
- You cherry-picked three commits with -n and committed once. How do you keep provenance?`-n` skips the commit, so no `(cherry picked from commit …)` line is generated. Write the source ids into the message yourself when you commit — one line per picked commit, or a short note naming the range. Otherwise the combined commit carries no record of where its content came from.
saying these in an interview costs you the question
- Thinking -x changes what content gets applied
- Believing -x links the commits in Git's ancestry graph
- Using -x when picking from a purely local branch
- Assuming the copy already records its origin without any flag
- Expecting the recorded id to survive a rewrite of the source branch