Porting a run of upstream fixes into a vendored copy that carries local patches: stage header sets per commit, trim the test file per step

Situation: a vendored C++ header library with local (downstream) changes, and an upstream branch that landed six hardening commits, each with its own test commit. Goal: one red/green pair per upstream commit.

What worked: 1. Build staged header sets in a scratch dir first: copy the vendored headers, then for each upstream commit git show <sha> -- include/a.h include/b.h | patch -p2 -F3. Hunks that touch locally changed code reject; port those by hand with a small script of exact string replacements, then re-apply the later commits on top. Check that the last stage equals an all-at-once port before touching the repo. 2. Make the test file from upstream's latest version, then drop functions per step with a generator: find static <type> name(, back up over its comment block, cut to the matching closing brace by brace counting. A plain search for the next \n}\n breaks on one-line functions and silently eats the next function too. Also drop tests for code you don't vendor, and keep older versions of tests whose newer form needs an API you haven't ported. 3. Each step: write the test variant and commit it (red), copy that stage's headers and commit (green).

Pitfalls: - An upstream test that calls a new API gives a compile-failure red, not a behavioural one. Say so in the commit message, or pair it with a behavioural test at your own call site. - Run your whole downstream suite after every green, not just the upstream tests. A stricter check upstream can change which error a hostile file hits first, and a downstream test that matches error text then goes red (it happened here; fixed forward). - Rejected hunks often mean the downstream copy already has an equivalent change. Diff before porting, so you don't apply it twice.