aidd is public again. git log on it returns one line. That
commit has no parents, the only tag in the repository points at it, and everything the project did
before it is unreachable from the branch.
I did a version of this in July, which I wrote about in
Deleting 11,400 Lines of Changelog Nobody Can Use. That pass collapsed the
published changelogs and republished. This one went further. The repository went private in early
September, I cut a new parentless root locally, and that root became main. The commits behind
it are no longer part of the public project.
The reason was distribution more than tidiness. v2 shipped prebuilt executables: eight Releases,
four assets each, something like 674 MB of binaries that no longer correspond to anything. v3 does
not ship executables at all. The Release carries GitHub’s own source archives and nothing else, and
you install it by running bun install against Bun 1.4.2 or newer. Leaving eight Releases of dead
binaries sitting above the new one, tagged as though they were the same product line, was worse than
starting the public line over. The five weeks of v2.131.0 through v2.142.0 were dogfooding
anyway. I wanted the new release to be the one people installed.
Before removing the public history, I took a private snapshot: the full 754 commits,
checked with git fsck, plus a separate capture of everything GitHub stores outside git and a clone
therefore never carries. The Release notes and their uploaded assets, the three pull requests with
their review comments, ninety-odd workflow runs, the topics, the one environment. Both the secrets
and variables lists came back empty, which was the answer I wanted and also the only part of that
capture I have looked at since.
The root itself I had to cut twice. The first one passed every gate on this machine, and then CI failed on Linux for two defects Windows could not surface. So I fixed both in source and cut the root again. A parentless commit gets a new identity even when the tree it carries is unchanged, which meant redoing all of the evidence against the second one: the quality gate, the dependency audit, a production rebuild, and a full screenshot capture across 45 routes that binds itself to the commit and its tree. The earlier capture was tied to the first root, so I couldn’t reuse it for the second.
Afterwards I downloaded the source zip the way a stranger would and installed from it in a temporary
directory. VERSION read 3.0.0, the frontend built in about twelve seconds, and the panel answered
/api/v1/health with a 200. One thing came out different from a git
checkout, which I had not thought about: the build stamp records no source attestation, because an
archive has no .git in it to read. That is correct behavior and it still looked wrong the first
time I saw the empty field.
The nine v2 tags were still sitting in my local checkout at that point, pointing into history the remote no longer had. I deleted them once I had confirmed each one matched its counterpart in the snapshot byte for byte. They were never pushed anywhere.
Spernakit has been public continuously since July 4 and none of this touched it.
The tag is out now, so I am treating it as immutable. If the root turns out to be wrong, it gets fixed in 3.0.1 rather than retagged.