PR #673 stopped the ADR KB blob from growing the repo further — it is now
untracked and ships as its own release asset. It did not reclaim what is
already written.
Current state
.git is ~405 MB- ~365 objects in history are
assets/mae-adr.cozo revisions alone, at ~57 MB
each regeneration
assets/mae-manual.cozo (~32 MB) and assets/mae-devpractices.cozo (~18 MB)
are still tracked and still regenerate on content change, so they continue to
add history at a slower rate
Why this wasn't done in #673
Reclaiming needs git filter-repo (or equivalent), which rewrites every commit
SHA. That invalidates every existing clone, every fork, and every open PR — each
one needs a re-clone or a rebase onto the rewritten history. It is the right
operation, at the wrong moment for a routine cleanup PR.
Proposed handling
Do it at a deliberate release boundary (v1.0 is the obvious candidate), with:
- an announced window, so contributors know their clones will need replacing
- all open PRs merged or closed first
- a full mirror backup taken before the rewrite, retained
- a scripted, reviewable rewrite (not an ad-hoc invocation), covering
assets/mae-adr.cozo and — if they have been untracked by then — the other
bundled KB stores
- verification that tags and release assets still resolve afterwards
Related, and worth deciding first
mae-manual.cozo and the two guidance KBs are read out of assets/ at runtime
by source builds, which is why #673 left them tracked. Giving them a fallback
(build-on-demand, or fetch like make fetch-adr-kb) would let them be untracked
too — and it is better to know whether they are in scope before a rewrite than
to need a second one later.
PR #673 stopped the ADR KB blob from growing the repo further — it is now
untracked and ships as its own release asset. It did not reclaim what is
already written.
Current state
.gitis ~405 MBassets/mae-adr.cozorevisions alone, at ~57 MBeach regeneration
assets/mae-manual.cozo(~32 MB) andassets/mae-devpractices.cozo(~18 MB)are still tracked and still regenerate on content change, so they continue to
add history at a slower rate
Why this wasn't done in #673
Reclaiming needs
git filter-repo(or equivalent), which rewrites every commitSHA. That invalidates every existing clone, every fork, and every open PR — each
one needs a re-clone or a rebase onto the rewritten history. It is the right
operation, at the wrong moment for a routine cleanup PR.
Proposed handling
Do it at a deliberate release boundary (v1.0 is the obvious candidate), with:
assets/mae-adr.cozoand — if they have been untracked by then — the otherbundled KB stores
Related, and worth deciding first
mae-manual.cozoand the two guidance KBs are read out ofassets/at runtimeby source builds, which is why #673 left them tracked. Giving them a fallback
(build-on-demand, or fetch like
make fetch-adr-kb) would let them be untrackedtoo — and it is better to know whether they are in scope before a rewrite than
to need a second one later.