fix-cherry-pick-pr

Fix Cherry-Pick PR

Overview

Repair and verify cherry-pick PRs in tikv/pd. Compare the source PR and the cherry-pick PR first, then fix the cherry-pick branch without losing release-branch-only code.

1. Identify the PR pair

• Inspect the cherry-pick PR with gh pr view <pr> --repo tikv/pd --json number,title,body,baseRefName,headRefName,headRepositoryOwner,url,commits.
• Extract the source PR number from one of:
  • a title suffix like (#10131)
  • body text like This is an automated cherry-pick of #10131
  • the head commit message when the body is ambiguous
• Read the linked issue if present to confirm the real bug and expected behavior.
• Treat GitHub mergeable status as insufficient. A PR can be mergeable while still containing committed conflict markers in the patch.

2. Compare source and cherry-pick diffs before editing

• Compare changed files first:

gh pr diff <source-pr> --repo tikv/pd --name-only
gh pr diff <cherry-pick-pr> --repo tikv/pd --name-only

• Compare the final aggregate diff, not raw commit count. Cherry-pick PRs can have extra cleanup commits.
• Normalize diff output when checking parity:

diff -u \
  <(gh pr diff <source-pr> --repo tikv/pd | awk '
      /^diff --git a\// { file = $4; sub("^b/", "", file); next }
      /^\+\+\+ b\// { file = substr($0, 7); next }
      /^--- a\// { next }
      /^[+-][^+-]/ && file != "" { print file ":" $0 }
    ' | sort) \
  <(gh pr diff <cherry-pick-pr> --repo tikv/pd | awk '
      /^diff --git a\// { file = $4; sub("^b/", "", file); next }
      /^\+\+\+ b\// { file = substr($0, 7); next }
      /^--- a\// { next }
      /^[+-][^+-]/ && file != "" { print file ":" $0 }
    ' | sort)

• Accept differences caused only by base-branch context:
  • different line numbers or surrounding unchanged context
  • branch-only helper or API definitions that must remain in the release branch
  • different deleted lines when the release branch had already diverged before cherry-pick
• Do not accept:
  • committed <<<<<<<, =======, >>>>>>> markers
  • missing behavior from the source PR
  • extra functional changes not required by the release branch

3. Prepare the working branch

• Keep the current worktree clean before switching.
• Fetch the cherry-pick head branch from its actual remote, often tichi or ti-chi-bot.
• Create a local tracking branch for the cherry-pick head. If the local branch name is free, prefer reusing the remote branch name directly.
• Confirm the expected head commit before editing.

Example:

git fetch tichi cherry-pick-10131-to-release-8.5
git switch --track tichi/cherry-pick-10131-to-release-8.5

• If the local branch name already exists or is occupied by another worktree, create a differently named local branch that still tracks the cherry-pick head.

4. Repair the cherry-pick patch

• Search touched files for conflict markers:

rg -n '<<<<<<<|=======|>>>>>>>' <touched-files>

• Resolve each block by reconstructing the final intended code. Do not blindly keep one side.
• Preserve three things at once:
  • the source PR's intended behavior
  • release-branch-only code that existed before cherry-pick and must remain
  • branch-specific adjacent APIs, helpers, or tests
• When the automated cherry-pick inserted conflict markers around an existing release-branch API, keep the API and insert the source PR logic beside it in the correct final location.
• If the cherry-pick introduced no real semantic drift beyond committed markers, keep the follow-up commit minimal. Remove markers and restore the intended final code only.

5. Verify in PD with failpoint discipline

• Follow PD's failpoint rules. If the touched tests rely on failpoints, do not rely on plain go test results before instrumentation.
• Prefer the narrowest targeted verification first. For the store-limit workflow used in #10131 and #10301:

make failpoint-enable
go test ./server/cluster -run 'TestCheckCache|TestStoreLimitChangeRefreshLimiter' -count=1 -v -timeout=2m
make failpoint-disable

• If you need broader signal, run the narrowest additional package or integration test target that covers the touched files.
• If that extra verification fails in unrelated packages, separate that from the cherry-pick fix. Report the failing package and test name rather than attributing it to the cherry-pick automatically.
• Before finishing, confirm:

rg -n '<<<<<<<|=======|>>>>>>>' <touched-files>
git diff -- <touched-files>
git status --short --branch

• If failpoint-generated files appear after an interrupted run, restore them with make failpoint-disable before committing or doing other non-test work.

6. Commit and push

• Use a focused follow-up commit that explains the cleanup, for example:

git commit -s -m 'storelimit: resolve cherry-pick markers in #10301'

• Push HEAD back to the existing cherry-pick head branch if you have permission.
• If push fails and the user did not specify a fallback, stop and report the push error instead of inventing a new branch plan.

7. Report the result

Include:

• source PR number and cherry-pick PR number
• whether the final cherry-pick diff matches the source PR semantically
• whether any extra behavior was introduced
• files repaired
• targeted tests run and their result
• any unrelated broader test failure that remains outside the cherry-pick fix

Common pitfalls

• Do not equate GitHub MERGEABLE with "patch is clean".
• Do not compare raw commit lists. Compare final diffs.
• Do not delete release-branch-only code when resolving a cherry-pick block.
• Do not leave failpoint-generated files in the working tree.
• Do not claim parity until you compare the final aggregate diffs after the fix.