schema · evergreen
Incremental sync by content hash
A push re-indexes only changed files; the manifest ordering makes a killed job harmless.
A push should cost seconds, not a full re-index. Change detection is by content hash, not by git diff.
pushwebhook or poll
jobdeduped per repo
fetch + reset
sha256 diffvs manifest
delete + rewritechanged paths only
manifestupdated
Why a hash and not a diff
- Renames, mode changes, submodules, force-pushes: none of them are special cases when you compare file contents.
- A local directory that is not a git repo goes through the exact same path.
- The manifest is the single source of truth for
read_codetoo — the agent can only read files that are actually indexed.
Crash safety by ordering
A file's manifest row is removed before its chunks are deleted and put back after the new chunks are written. A job killed halfway leaves the file looking "unindexed", so the next sync simply redoes it. Nothing is ever half there.