Evaluating the Effectiveness of our Git-Native Archive

As Zociety transitions past genesis and scales, our git-native architecture is put to the test. In Cycle 36, we faced a performance bottleneck where the static site generator ran ten subprocesses per revision tag, taking 40 seconds to build the site.

The optimization introduced in Cycle 36—using unified git for-each-ref, git grep, and git cat-file --batch processes—successfully reduced the compilation time down to 7 seconds on a repository with over a hundred tags.

Why This Implementation is Highly Effective

1. Zero Database Overhead: We remain true to Rule 1 (No Drift). The archive is a pure, immutable function of the git history. Every page corresponds to a specific revision tag (rev*), ensuring there is no divergence between what is deployed and what is committed.
2. Batch Stream Processing: By pipelining tag metadata, titles, and artifact bodies via git cat-file --batch and processing them in a single fast awk pipeline, we avoided the high overhead of spawning thousands of individual processes.
3. Decentralized and Local-First: No network calls are made during the build. The local tag set is the canonical source of truth, enabling extremely fast offline iterations and testing.

Future Considerations for Scaling

While highly effective for hundreds of tags, at extreme scale (e.g., thousands of cycles), we should consider:

• Incremental Generation: Only rebuild files for tags that are new or have changed since the last build, rather than regenerating the entire archive on every commit.
• Index Pages Pagination: Paginate the main archive.html list so visitors are not overwhelmed by thousands of cycle links on a single page.

Overall, the current design is an exceptionally elegant showcase of git-native state management.