fix(tools): a dirty flag that fired on scratch files - #265
Merged
Conversation
Found by running the thing rather than by reading it. The first real build off the stamp mechanism (502d45a, 2026-09-06) reported itself as -dirty and printed the "this binary does NOT match its commit" warning. The binary matched its commit exactly. The two files responsible were tmp/editmode-new.xml and tmp/editmode-resend.xml -- untracked test-result scratch that cannot enter a player build by any path. The check asked `git status --porcelain` over the whole tree. The question it is actually asking is "does $commit describe the code in THIS BINARY", and only Ironfront_Reborn/ becomes the binary: Assets (including the prebuilt Ironfront.Net.* DLLs under Assets/Plugins), Packages and ProjectSettings. An artifacts/ run, a tmp/ scratch file, or an edit to this very script cannot change what Unity compiles. WHY THIS IS WORTH A COMMIT RATHER THAN A SHRUG. The flag exists so a reader can tell a SHA that describes the binary from one that does not. Firing it on scratch makes it fire on nearly every build, and a warning that is always on is one nobody reads by the second day -- at which point the one build where it matters says the same thing every other build said. The BuildStampTests remark makes this exact argument about the mismatch error; it applies here and the first run proved it. MEASURED IN BOTH DIRECTIONS, on the same machine, same commit. before: untracked tmp/*.xml -> "502d45a-dirty" + warning (false alarm) after: uncommitted tools/ + docs/ -> "502d45a", silent (correct) and the second build still stamps: the new Server.dll carries 2026-09-06T10:03:18Z and NOT the earlier 09:58:40Z, so the assemblies were genuinely recompiled and the stamp tracks each build rather than being copied forward. The warning text now names the directory it checked, so a reader who disagrees with the scope can see what it was.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to #264, found by running the mechanism rather than by reading it.
The first real build off the new stamp reported
502d45a-dirtyand printed "thisbinary does NOT match its commit". The binary matched its commit exactly. The
culprits were
tmp/editmode-new.xmlandtmp/editmode-resend.xml— untrackedtest-result scratch that cannot enter a player build by any path.
The check asked
git status --porcelainover the whole tree. The question it isactually asking is "does this SHA describe the code in this binary", and only
Ironfront_Reborn/becomes the binary — Assets (including the prebuiltIronfront.Net.*DLLs underAssets/Plugins), Packages and ProjectSettings.Why this is worth a commit and not a shrug
The flag exists so a reader can tell a SHA that describes the binary from one that
does not. Firing on scratch makes it fire on nearly every build, and a warning
that is always on is one nobody reads by the second day — at which point the one
build where it matters says exactly what every other build said.
BuildStampTestsmakes this argument about the mismatch error in its own remark; the first run
proved it applies here too.
Measured in both directions
Same machine, same commit:
tmp/*.xml502d45a-dirty+ warning — false alarmtools/+docs/edits502d45a, silent — correctAnd the second build still stamps: the new
Ironfront.Net.Unity.Server.dllcarries2026-09-06T10:03:18Zand not the earlier09:58:40Z, so the assemblies weregenuinely recompiled and the stamp tracks each build rather than being copied
forward.
End-to-end proof the stamp works at all
While confirming this, the mechanism was verified in a built binary for the first
time —
502d45aappears exactly once in bothIronfront.Net.Unity.Server.dllandIronfront.Net.Unity.Shared.dll, the literaldevis gone from both (so thesubstitution is total, not additive), and
git statusis clean afterwards (thefinallyrestored the sources).One note for anyone repeating that check:
stringsdefaults to ASCII and .NETstores string literals as UTF-16, so a naive probe returns 0 on a perfectly good
DLL. Use
strings -a -e l, and confirm the probe against a literal you know isthere before trusting a zero.