Cross repo cherry pick

Cross-repo cherry-pick (with line-ending intelligence)

When to use this

You have two git repositories with unrelated histories:

• Source repo: an old development repository with commits you want to ship.
• Target repo: a newer repository that was initialised from a different starting point (often: a live production server's current state).

You want to bring specific commits — or a contiguous range, or "everything since commit X" — from source into target. Crucially:

• You do not want to merge the histories. They're unrelated; merging would be nonsense.
• You do not want a single giant "initial sync" commit; you want the actual content of those specific commits.
• You want the target's git history to make sense as "mirror of prod, plus these intentional changes."

This is harder than it sounds because:

• git cherry-pick works only when commits live in the same DAG.
• git format-patch + git am fails across repos because patches reference parent blob SHAs that don't exist in the target.
• Working-tree files often have different line endings between the two repos (Windows checkout = CRLF; production pull = mixed CRLF/LF). Naive copy produces a "huge diff" that's 95% line-ending noise.

The right approach (chosen after trial-and-error)

1. Identify the file set. What files were touched in the commit range you want?
2. Detect line-ending convention in the target repo for those files (per-file).
3. Extract content from source git blobs, not from the source working tree. Source git stores LF (typically); working tree may have CRLF after checkout.
4. Write content to target with the target's line-ending convention (per-file match).
5. Verify diff with --ignore-all-space to see the actual content delta vs the line-ending noise.
6. Commit on a non-deployed branch with a message preserving the source commit summaries.

Concrete protocol

Step 1 — identify files in the commit range

In the source repo:

# range: from <start>^ (exclusive) to <end> (inclusive)
git diff --name-status <start>^..<end>

Output is M for modified, A for added, D for deleted, R for renamed. List of files is your work scope.

For a single commit:

git diff --name-status <commit>^..<commit>

Step 2 — line-ending detective

Don't trust assumptions. Check actual bytes per file in both repos.

# In source repo — what's in the git blob (typically LF)
git show HEAD:<file> | head -1 | od -c | head -1

# In source repo working tree — what's on disk (often CRLF after Windows checkout)
head -1 <file> | od -c | head -1

# In target repo — what's in HEAD
git -C <target> show HEAD:<file> | head -1 | od -c | head -1

You're looking for \r \n (CRLF) vs just \n (LF) at the end of the first line.

Common findings:

Source git blob	Source working tree	Target git blob	Implication
LF	CRLF (autocrlf checkout)	LF	Easy — extract from blob, write to target
LF	CRLF	CRLF	Extract from blob, convert LF→CRLF, write
LF	CRLF	Mixed (some files LF, some CRLF)	Per-file detection required

A 17-year-old PHP codebase that has been touched by both Windows and Linux editors will be inconsistent — some files LF, some CRLF, in the same repo.

Step 3 — extract from blobs (not working tree)

# Get the LF-correct content of the source file at HEAD (or any commit)
git -C <source> show HEAD:<file> > /tmp/blob-content

This gives you exactly what's in git, with no checkout-time conversion.

Step 4 — match target's convention

Per file, check target's line ending and convert if needed:

# Detect target's convention for a file
target_ending=$(git -C <target> show HEAD:<file> 2>/dev/null | head -c 4096 | grep -c $'\r')

# If $target_ending > 0, target uses CRLF for this file
if [ "$target_ending" -gt 0 ]; then
    sed 's/$/\r/' /tmp/blob-content > /tmp/final-content
else
    cp /tmp/blob-content /tmp/final-content
fi

cp /tmp/final-content <target>/<file>

Step 5 — verify the actual diff

cd <target>
git status -s              # files changed
git diff --stat            # raw diff (will look huge if lines differ)
git diff --stat --ignore-all-space   # real content delta

Expect a discrepancy: if a file had CRLF in source-git's blob (rare) but you wrote LF to target, every line will show as changed in the raw diff. The --ignore-all-space view is the source of truth for "what content actually changed."

If the --ignore-all-space numbers match what the source commits' git log --stat showed, you applied the changes correctly.

Step 6 — commit on a safe branch

cd <target>
git checkout -b dev   # if not already on a non-deployed branch
git add -A
git commit -m "$(cat <<'EOF'
feat: apply <feature-name> from <source-repo> to prod-mirror

Cherry-picks commits <range> from <source-repo>:

  <commit-sha-1> <message-1>
  <commit-sha-2> <message-2>
  ...

Files:
- <file-1>
- <file-2>

Note: line endings normalized to <LF|CRLF|mixed> to match target convention.
Real content delta (ignoring whitespace): +X / -Y lines.
EOF
)"

Push to a branch that does not auto-deploy. If your CI deploys on main push, push to dev or any other branch.

A more robust automated version (Bash one-liner)

For when you trust the protocol:

#!/usr/bin/env bash
# cross-repo-cherrypick.sh <source-repo-dir> <target-repo-dir> <range>
# e.g.: ./cross-repo-cherrypick.sh ~/old-dev ~/prod-mirror 6548e50^..HEAD
set -euo pipefail

SRC="$1"
DST="$2"
RANGE="$3"

# 1. List files
files=$(git -C "$SRC" diff --name-only "$RANGE")

# 2. For each file, extract from source blob, match target convention, write
while IFS= read -r f; do
    [ -z "$f" ] && continue
    mkdir -p "$DST/$(dirname "$f")"
    
    # Extract source content (blob — LF normalized)
    src_content=$(git -C "$SRC" show "HEAD:$f" 2>/dev/null) || {
        echo "MISSING in source HEAD: $f"
        continue
    }
    
    # Detect target convention (default to LF if file doesn't exist yet)
    target_uses_crlf="no"
    if [ -f "$DST/$f" ]; then
        if head -c 4096 "$DST/$f" | grep -q $'\r'; then
            target_uses_crlf="yes"
        fi
    fi
    
    # Write with appropriate line ending
    if [ "$target_uses_crlf" = "yes" ]; then
        printf '%s' "$src_content" | sed 's/$/\r/' > "$DST/$f"
    else
        printf '%s' "$src_content" > "$DST/$f"
    fi
    echo "OK $f"
done <<< "$files"

echo "Done. Run \`cd $DST && git diff --stat --ignore-all-space\` to verify."

CRLF / LF detective protocol (sub-skill)

When you see a "huge git diff that doesn't make sense":

1. Check the file's blob in HEAD on both sides. Use git show <ref>:<file> | head -1 | od -c | head -1.
2. Check the file on disk in both working trees. Use head -1 <file> | od -c | head -1.
3. Compare. Find the mismatch.
4. Decide which convention you want to standardize on for the target repo.
5. Convert before committing. Use sed 's/\r$//' (CRLF→LF) or sed 's/$/\r/' (LF→CRLF).
6. Re-check git diff --stat --ignore-all-space to verify actual content matches expectations.

The pattern: git diff output is very rarely lying about content. It IS often lying about how much you actually changed, because line endings inflate the apparent diff. Always cross-check with --ignore-all-space.

Why this skill exists

In one engagement, this exact problem ate ~45 minutes:

1. Copied working-tree files from source to target. ❌ Broken — Windows checkout had CRLF, target had LF for some files.
2. Converted all to LF. ❌ Broken — some target files were CRLF; converting introduced new diffs.
3. Tried git am with patch files. ❌ Broken — blob SHAs don't exist across repos.
4. Tried git apply --3way. ❌ Broken — same SHA problem.
5. Finally: extracted blobs from source git (always LF), detected target convention per file, wrote with matching convention. ✅ Works.

The trial-and-error was costly because every attempt produced a "huge diff" that looked plausible at first glance — you have to dig in to realize it's line-ending noise. Skip the chain by using this protocol from step 1.

Common mistakes to avoid

• Trusting cp to preserve line endings. It does (binary copy). But the source working tree itself may have CRLF that the source's git blob doesn't have. The blob is the truth.
• Running dos2unix blindly across all files. Some prod files genuinely have CRLF (legacy Windows uploads). Don't normalize without checking the target's existing convention.
• Using git am for cross-repo work. It needs SHAs. They don't exist. It will fail. Don't waste time.
• Trusting the "huge diff" number. Always cross-check with --ignore-all-space. The real number is usually 5–10% of the displayed number.
• Committing the result to main directly. If your target has auto-deploy, this ships untested code. Always use a branch that doesn't auto-deploy.

Output format

When you complete a cross-repo cherry-pick, produce a summary:

Source: <repo> <range>
Target: <repo> <branch>
Files: <count> (M: ..., A: ..., D: ...)
Raw diff:           +<X> / -<Y>
Content diff:       +<X'> / -<Y'>      (--ignore-all-space)
Line-ending noise:  <X-X'> + <Y-Y'>
Commit:             <sha>
Branch:             <branch> (push manually when ready)

This makes the actual scope of the change reviewable.