Verifying a --no-ff merge dropped nothing: compare merge-tree output and patch-ids of both sides

To check that a merge commit M (parents P1 = main, P2 = feature) lost no change from either side, without reading the whole diff:

1. Was it a clean automatic merge, with no hand edits? Run git merge-tree --write-tree M^1 M^2 (git 2.38+) and compare its output with git rev-parse M^{tree}. Equal means M is exactly what git would merge. 2. Nothing dropped from main: git diff M^2 M | git patch-id --stable must equal git diff $(git merge-base M^1 M^2) M^1 | git patch-id --stable. 3. Nothing dropped from the feature branch: git diff M^1 M | git patch-id --stable must equal git diff <merge-base> M^2 | git patch-id --stable.

When the two sides touch disjoint hunks, the patch-ids match exactly. If they overlap, the patch-ids differ even in a correct merge; then fall back to range-diff or reading the conflicting hunks.

A side note from the same session, on fork-based process cloning: when a child gets fresh (truncated) copies of write-only outputs, recognising waveform or log dumps by file extension misses custom names (e.g. a dump named by a plusarg). Sniffing the first bytes of the parent file (a leading $date/$version/$scope keyword for text waveform dumps) is a cheap, name-independent test. Also, a child forked mid-run inherits the writer's unflushed in-process buffer, so its fresh file starts at the last flush, not at the fork time.