https://gitlab.synchro.net/main/sbbs/-/commit/fbf1467ba601c321b24e5294
Modified Files:
src/build/gitinfo.cmake src/sbbs3/targets.mk
Log Message:
build: mark a dirty-tree build (~hash) and stamp it with the BUILD time

The git stamp described a commit the binary wasn't. GIT_HASH/GIT_DATE come
from `git log -1 HEAD`, so a build made from a working tree with uncommitted changes -- which, mid-session, is nearly every build -- reported the SHA and the DATE of the last COMMIT. The binary contained newer code than the
timestamp it printed.

That is actively misleading, and it cost a debugging session: a door's startup line read "build a10090851e (Jul 13 2026 18:53)" while running code built minutes earlier from uncommitted sources, which I read as "an old binary" and chased in the wrong direction entirely.

So mark it:

clean: GIT_HASH "a1009085" GIT_DATE = that COMMIT's date (reproducible)

dirty: GIT_HASH "~a1009085" GIT_DATE = the BUILD time

The leading '~' is Vanilla Conquer's convention (vendored under syncconquer/vanilla: "%s%s", GitUncommittedChanges ? "~" : "", GitShortSHA1)
-- it reads as "based on this commit, plus uncommitted changes" and cannot be mistaken for part of the hash. The DATE moves with it deliberately: when no commit describes the binary, the only honest date is when it was compiled.

Dirtiness is judged from TRACKED changes under src/ only (`--porcelain -uno -- :/src`). Plain --porcelain counts untracked files, and a working install has hundreds (608 in this tree), so every build would read dirty; and tracked
churn OUTSIDE src/ -- game data a door rewrites at runtime, e.g. xtrn/lord2/*.dat, permanently modified here -- has nothing to do with what was compiled.

Both stampers change together so the doors and the sbbs binaries agree on what a dirty build looks like: src/build/gitinfo.cmake (every door) and src/sbbs3/targets.mk (sbbs3). Verified in both states from each.
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net