YETUS-983. test-patch confused by multiple commits that include rename

[ndimiduk]

Flip dryrun_both_files to prefer cumulative .diff over per-commit .patch. The cumulative diff represents the PR's net change, avoiding stale files left on disk when format-patch stanzas add then rename/delete the same file.

Generate the local diff with git diff --binary to preserve binary file handling that GitHub's API .diff endpoint strips. Fall back to the API .diff when local generation fails.

[ndimiduk]

Okay I think I tracked this down. Looks like git apply processes per-commit format-patch stanzas sequentially against the working tree, but each stanza's precondition check assumes the file is in its pre-stanza state — not the state left by earlier stanzas. When a file is created in commit 1, modified in commit 2, and deleted in commit 3, the file persists on disk despite the apply claiming success. git apply --check (dry-run) also passes, because it validates stanzas independently rather than simulating the cumulative effect (using MacOS git 2.50.1). I added a bats test that I think reproduces.

The cumulative git diff output doesn't have this problem — it represents the net change from base to HEAD as a single stanza per file. A file that was added and later deleted simply doesn't appear. A file that was added and later renamed appears only at its final path.

In the patch I swap the logic of dryrun_both_files to prefer the cumulative .diff over the per-commit .patch. The .patch is kept as a fallback.

[aw-was-here]

If I remember correctly, the problem was that the diff format didn't support binary files so tests and the like would be missing content.

[ndimiduk]

If I remember correctly, the problem was that the diff format didn't support binary files so tests and the like would be missing content.

That's what I thought. Looks like the world has changed since then, at least, I think that's what my new test is showing.