Task Summary
Harden the backport automation's git cherry-pick invocations against package/directory renames that land between main and a release/* branch.
The mechanism is already correct — both backport scripts use git cherry-pick (a 3-way merge with rename detection), not patch/git apply, so a renamed file is normally followed to its new path automatically. The problem is that both call sites invoke cherry-pick bare, leaving three merge knobs at defaults that misbehave exactly when a large package rename is in play:
merge.renameLimit / diff.renameLimit — when the number of unpaired added/deleted paths exceeds the limit, Git silently disables inexact rename detection (only a warning is printed). A package-wide rename touches many files and can blow past the default, so renamed files degrade back to "deleted + added", the picked hunks land on paths that no longer exist, and we get spurious conflicts.merge.directoryRenames — defaults to conflict. When the backported commit adds a new file under the old package path, Git will not auto-place it into the renamed directory; it raises a conflict instead. Backports that add files are common here (the feature-absent guard in create-backport-branch.sh explicitly accounts for added files).rename-threshold — a package rename that also rewrites the package/import lines can drop a small file's similarity below the default 50% and miss the rename.
Affected code
.github/scripts/prepare-backport-checkout.sh — pre-merge preflight cherry-pick of the squashed range..github/scripts/create-backport-branch.sh — post-merge fallback cherry-pick that opens the draft backport PR.
Both call sites must be changed identically, otherwise the preflight (script 1) and the branch it later builds (script 2) can disagree ("green preflight, then conflict").
Proposed change
Wrap both cherry-pick calls with:
git -c merge.renameLimit=999999 \
-c diff.renameLimit=999999 \
-c merge.directoryRenames=true \
cherry-pick -Xrename-threshold=40% ...
Pure configuration passthrough to the merge machinery — no logic change, no new dependencies.
Task Type
Task Summary
Harden the backport automation's
git cherry-pickinvocations against package/directory renames that land betweenmainand arelease/*branch.The mechanism is already correct — both backport scripts use
git cherry-pick(a 3-way merge with rename detection), notpatch/git apply, so a renamed file is normally followed to its new path automatically. The problem is that both call sites invokecherry-pickbare, leaving three merge knobs at defaults that misbehave exactly when a large package rename is in play:merge.renameLimit/diff.renameLimit— when the number of unpaired added/deleted paths exceeds the limit, Git silently disables inexact rename detection (only a warning is printed). A package-wide rename touches many files and can blow past the default, so renamed files degrade back to "deleted + added", the picked hunks land on paths that no longer exist, and we get spurious conflicts.merge.directoryRenames— defaults toconflict. When the backported commit adds a new file under the old package path, Git will not auto-place it into the renamed directory; it raises a conflict instead. Backports that add files are common here (the feature-absent guard increate-backport-branch.shexplicitly accounts for added files).rename-threshold— a package rename that also rewrites thepackage/importlines can drop a small file's similarity below the default 50% and miss the rename.Affected code
.github/scripts/prepare-backport-checkout.sh— pre-merge preflight cherry-pick of the squashed range..github/scripts/create-backport-branch.sh— post-merge fallback cherry-pick that opens the draft backport PR.Both call sites must be changed identically, otherwise the preflight (script 1) and the branch it later builds (script 2) can disagree ("green preflight, then conflict").
Proposed change
Wrap both
cherry-pickcalls with:Pure configuration passthrough to the merge machinery — no logic change, no new dependencies.
Task Type