nethersx2-turnip-classic documents the shim rules of the revision it
pins, and says so in prose: the classic build is that revision. Compared
to HEAD it reported the same two changes every pass, and recaling would
have repointed its refs at rules this build never had.
pin_frozen says the freeze is deliberate, and the profile is then judged
against its own revision, exactly as one pinned to a superseded tag
already was. Recale and bump are refused for it, which is what makes the
declaration safe to trust.
A recale rewrites the located tokens and leaves the sentence alone, so a
prose run keeps `a.c:228, 1439-1443` while the rendered form drops the
space. Comparing the two literally made a run that had just been written
look unwritten, pending_recale counted it, and bump_commit refused for
ever.
mariani was held back by three of them: it recaled twenty-five refs and
could never advance its pin, which is the desync the all-or-nothing rule
forbids. 67 refs, all anchored.
openbor.c is 55k lines at the pin and 57k at HEAD, over a ceiling of
40k, so its ref reported CHANGED with nothing to act on: the mapping was
never attempted. Diffing that pair takes nine seconds, and the fallback
only runs once exact anchoring has failed, which is rare.
The ceiling now sits above it and still stops a pathological pair from
stalling a sweep of every profile. savesettings moved from 2675 to 2940
and the range maps cleanly.
The diagnostic caught a ref whose file was missing at the pin. nestopia
showed the other shape: the file is there and the line is not yet. Its
palette and database loads were cited at 2041 and 2063, which is where
HEAD carries them, against a pin four hundred lines shorter, and that
reported as a plain GONE with nothing to act on.
A cited line past the end of the pinned file that fits HEAD is the same
finding as before and now says so. nestopia's pin moved to the revision
its refs describe: 8 refs, all anchored.
Recaling refs while the pin stays put produces exactly the state the
all-or-nothing rule exists to prevent: a profile whose refs describe one
revision and whose source_commit names another. The tool manufactured it
on mariani, where three prose runs it could not rewrite kept
bump_commit refusing while eleven refs had already moved.
Asking for both writes is now atomic. The work happens on a copy, which
is promoted only when the pin follows, and a rebase is refused outright
when something visible beforehand will hold the pin: an annotated ref,
one under a mode key, or a prose run whose tokens cannot be located well
enough to rewrite. Where the block only appears after the write, the
copy is discarded and the profile is named on stderr rather than left
half moved.
mariani is back on its pin and stays at four refs to read, which is
honest: three of them have to be rewritten by hand before anything can
advance.
kenji-nx cited tmp/es-de/ANDROID.md:470-474, a path from the machine of
whoever profiled it. No revision of any declared repository holds it, so
profile_sync could only report it missing, every pass, forever, and no
amount of reading would ever settle it.
validate_schemas now refuses a scratch directory, an absolute path, a
Windows drive path and one climbing out of the tree, and names the
offending citation rather than the scalar that carries it. Offline, so it
runs on every push and every pull request rather than waiting for a
network pass.
The ES-DE citation reads as external now, which is what it always was.
kenji-nx is at 37 refs, all anchored: the three changed blocks were var
giving way to explicit types.
An empty file list is the one assertion here that ages unwatched. Nothing
can go missing and no ref can drift, so nothing notices when a core that
embedded everything grows a path. virtualjaguar said "No external BIOS
files are required or loaded by this core" while its source had grown
eleven filenames read from the system directory, and only a reading
found it.
fileless_audit looks for the request itself, the system directory ask, in
the sources each profile already cites. Over the 151 fileless profiles it
named eleven, of which two were covered by data_directories, six carried
an exclusion_note, and three had nothing written down at all: craft
writes its world database in that directory, dice stores the answer in a
variable no other file in the tree names, lutro hands it to the Lua game.
Each now says so.
The check settles: declared files, a declared directory, or a written
answer all end it, so what it reports is the set nobody has read yet. A
test holds the corpus at zero.
profile_sync follows content, so a ref that drifted still anchors where
the cited text went. That is drift detection working, and it cannot
answer the only question a MAME romset ref asks: does this line declare
this set. It flagged five refs in one driver file where nineteen were
stale, the fourteen others having been relocatable somewhere plausible.
mame_ref_audit asks the stronger question and found ninety-two across
the four profiles whose upstream still moves: mame 66, mamearcade 18,
mamemess 6, groovymame 2. Each had exactly one declaration to point at.
The frozen generations, mame2009 through mame2016, come out clean, which
is the check saying it finds drift only where drift can happen.
The set name is argument 1 of the machine macro. Matching it anywhere on
the line matches every clone naming it as parent, which is most of a
driver, and comments are stripped first because a declaration can sit
behind one. A set no machine declares is reported as not judgeable, not
wrong: device archives take their DEFINE_DEVICE_TYPE shortname.
Saying those profiles would stay open no matter what was wrong. A dead
forge is a verifiable fact, and a fact can be recorded: upstream_gone
carries why, and the profile stops being an open problem. The refs
describe the last revision anyone could reach, which is all any reader
can ask of them.
The declaration is guarded rather than trusted, because a forge can come
back and a profile that keeps asserting a death nobody rechecks is worse
than one that fails loudly. Declared and unreachable reports as a
recorded fact; declared and answering reports as the contradiction it
is, and the profile has to be read again.
yuzu and suyu carry GitHub's 451. citron carries the loss of
git.citron-emu.org and the squatter now sitting on the .com. Each names
what was probed and when, so the next reader retraces it rather than
repeating it.
A ref whose file is absent at the pinned revision reported "pin revision
missing", which reads as code that vanished. When the same file is at
HEAD and the cited range fits it, nothing vanished: the ref was written
against HEAD while source_commit still names an older revision, and the
profile describes two trees at once. The reason now says so, because the
fix is the pin and not a hunt for a move that never happened.
This is the state three profiles were left in during their own
reprofiling, against a warning the repository already carries. A range
that overruns HEAD stays a plain miss, and a file absent from both
revisions is unchanged.
Abdessamad Derraz