StateRehydrator.load_latest_state (gitgalaxy/core/state_rehydrator.py) picks its baseline as SELECT commit_hash FROM repo_data WHERE repo_name=? ORDER BY commit_date DESC LIMIT 1. That was right when a DB held one lineage scanned forward, but the exposure-history program (#2982) accumulates MANY commits of one repo in a single DB — the engine schema's (repo_name, commit_hash) keying supports it natively — and there:
- "latest by commit_date" is not "the baseline I mean": an event-pair DB holds commits in arbitrary historical order, so an incremental scan against it rehydrates whichever commit happens to have the newest author date, then
git diff <that> produces a nonsense delta set silently.
- Even forward walks aren't safe: commit dates are not monotonic (rebases, clock skew, imported history).
Ask: load_state(repo_name, commit_hash=None) — explicit baseline, None keeping today's latest-by-date behavior — threaded through as --incremental DB --baseline <sha> (default unchanged, fully backward-compatible). execute_incremental_scan itself needs nothing: it already receives the rehydrated state and diffs against the baseline commit recorded in it.
This unlocks the longitudinal mode #2982 is heading toward: onboard at commit X with one full scan, then walk history applying --incremental --baseline <previous> per commit — the Ripple Effect already recomputes the dependency graph, risk assembly and network layer over all files per delta, and the DB accumulates every commit's file/function state non-destructively under its own hash. Interim workaround (how the parity audit runs today): a per-pair scratch DB seeded with only the parent scan, where latest == parent by construction.
StateRehydrator.load_latest_state(gitgalaxy/core/state_rehydrator.py) picks its baseline asSELECT commit_hash FROM repo_data WHERE repo_name=? ORDER BY commit_date DESC LIMIT 1. That was right when a DB held one lineage scanned forward, but the exposure-history program (#2982) accumulates MANY commits of one repo in a single DB — the engine schema's(repo_name, commit_hash)keying supports it natively — and there:git diff <that>produces a nonsense delta set silently.Ask:
load_state(repo_name, commit_hash=None)— explicit baseline,Nonekeeping today's latest-by-date behavior — threaded through as--incremental DB --baseline <sha>(default unchanged, fully backward-compatible).execute_incremental_scanitself needs nothing: it already receives the rehydrated state and diffs against the baseline commit recorded in it.This unlocks the longitudinal mode #2982 is heading toward: onboard at commit X with one full scan, then walk history applying
--incremental --baseline <previous>per commit — the Ripple Effect already recomputes the dependency graph, risk assembly and network layer over all files per delta, and the DB accumulates every commit's file/function state non-destructively under its own hash. Interim workaround (how the parity audit runs today): a per-pair scratch DB seeded with only the parent scan, where latest == parent by construction.