The GitHub Actions job "Required Checks" on 
texera.git/gh-readonly-queue/main/pr-6964-db2c212d6f8c56a0a3d3560f8f8c0b35946aed1c
 has failed.
Run started by GitHub user Yicong-Huang (triggered by Yicong-Huang).

Head commit for run:
ad67b62af4c879cc00389cf00e7ef6c7105972bc / Yicong Huang 
<[email protected]>
ci: harden backport cherry-pick against package/directory renames (#6964)

### What changes were proposed in this PR?

The backport automation already uses `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. But every `cherry-pick`
call site invokes it **bare**, leaving three merge knobs at defaults
that misbehave precisely when a **package/directory rename** lands
between `main` and a `release/*` branch — producing spurious conflicts
on backports that would otherwise apply cleanly.

This PR wraps all backport `cherry-pick` invocations with the same three
settings:

```
git -c merge.renameLimit=999999 \
    -c diff.renameLimit=999999 \
    -c merge.directoryRenames=true \
    cherry-pick -Xrename-threshold=40% ...
```

- **`merge.renameLimit` / `diff.renameLimit`** — Git silently skips
inexact rename detection once the number of unpaired added/deleted paths
exceeds the limit (warning only). A package-wide rename can blow past
the default, degrading renamed files to "deleted + added" so picked
hunks land on paths that no longer exist. Raised so detection stays on.
- **`merge.directoryRenames=true`** — the default `conflict` will not
auto-place a file the backport *adds* under an old package path into the
renamed directory. Backports that add files are common here (see the
feature-absent guard in `create-backport-branch.sh`).
- **`-Xrename-threshold=40%`** — a rename that also rewrites
`package`/`import` lines can drop a small file's similarity below the
50% default and miss the rename.

Applied **identically** at all three cherry-pick call sites so no stage
can disagree with another over a rename:

- `.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.
- `.github/workflows/direct-backport-push.yml` — post-merge green path
that cherry-picks straight onto the release branch (thanks @xuang7 for
catching this one).

Pure configuration passthrough to the merge machinery — no control-flow
change, no new dependencies.

### Any related issues, documentation, discussions?

Closes #6963

### How was this PR tested?

This is a configuration-only change to two shell scripts and one
workflow's shell step, with no control-flow change. Verified `bash -n`
(syntax) on the edited scripts and YAML parse on the workflow. The added
`-c` flags and `-Xrename-threshold` are standard, long-supported `git
cherry-pick` / merge-machinery options, so behavior on the existing
(no-rename) path is unchanged; the new settings only take effect when a
rename is present, which is exactly the case that previously conflicted.
No unit tests exist for these CI helper scripts, and the real end-to-end
path (backport preflight + Direct Backport Push) exercises them on the
next backport-labeled PR.

### Was this PR authored or co-authored using generative AI tooling?

Generated-by: Claude Code (Opus 4.8)

---------

Co-authored-by: Claude Opus 4.8 (1M context) <[email protected]>

Report URL: https://github.com/apache/texera/actions/runs/30383134245

With regards,
GitHub Actions via GitBox

Reply via email to