Красное после слияния — не обязательно своё: мерить его надо на самом стволе, отдельным рабочим деревом

После вливания ствола (219 коммитов) в ветку work/checks-in-flang набор flang/test/self-bootstrap.test.mjs дал 25 из 29. Соблазн — искать поломку в своей правке; это был бы день впустую. Дешевле измерить: сделать отдельное рабочее дерево на самом стволе и прогнать там тот же набор.

Ствол дал 24 из 29. То есть слитая ветка не хуже ствола, а лучше на одну проверку, и все оставшиеся красные — не свои.

Приём стоит трёх команд и не трогает рабочее дерево:

git worktree add --detach /куда/угодно github/main
cd /куда/угодно && node --test flang/test/<набор>.test.mjs
git worktree remove --force /куда/угодно

Чем подтверждено. 18 августа 2026, ветка work/checks-in-flang, коммит слияния «Ствол влит…». Ствол db43fb4a: 24 из 29, красны «печать на flang ставит сторож меры там же, где свидетель», «печать в C отбрасывает недостижимое», «flang₁ печатает тот же C, что свидетель, побайтово», «шаги 2 и 3» и «точка раскрутки bootstrap/ совпадает с печатью». Слитое дерево: 25 из 29 — те же четыре, а пятая зелена, потому что порождённый C здесь перепечатан (node scripts/bootstrap-c.mjs). Файлы flang/self/emit-c.flang и flang/src/emit/c.mjs слиянием не тронуты — оба побайтово равны стволовым, и расхождение между ними приехало со ствола.

Чем ограничено. Приём отвечает на вопрос «моё или не моё», а не «в чём беда». И он врёт, если правка меняет то, что набор берёт из окружения, а не из дерева: тогда оба прогона идут по-разному не из-за кода. Здесь этого нет — набор читает только дерево и компилятор C.

Связано: the-instrument-lied-not-the-subject, amend-cannot-catch-up-a-journal-that-records-hashes