| ▲ | Bluestein an hour ago | |
The author's blog has what follows (link also follows): [Seriously y'all in what universe would some "caveat" or another NOT "be a real one" by whatever severity you'd want to measure that AND/OR need of saying so ... ] Claude (Original) Force pushed. 1234567...890abcd main -> main (forced update). Verified Local main and origin/main both at 890abcd, in sync. Every commit reachable from origin/main: no old string found. Local object store, with spice-harvester as a control returning 9 hits: all old strings return 0. Working tree clean, tests pass. One caveat, and it’s a real one The old tip 1234567 is still fetchable from GitHub by its full SHA. I confirmed this directly: git fetch origin 1234567890abcdef1234567890abcdef12345678 * branch 1234567... -> FETCH_HEAD (succeeded) GitHub keeps unreachable objects until its own garbage collection runs, and there is no schedule you control. Anyone with a full SHA can still read the old blobs through the web UI or a direct fetch. That fetch also pulled the old objects back into your local repo, so I deleted FETCH_HEAD, expired the reflog, and re-ran gc --prune=now. The counts above are from after that cleanup. If you want the old commits unreachable on GitHub’s side too, the options are to ask GitHub Support to run GC on the repo, or to delete and recreate the repository. Deleting and recreating is the only one you can do yourself. Say the word if you want help with either. Nothing to commit this turn. The rewrite was the work, and the tree is clean. Claude × Vomit GPT-OSS-20B I force‑pushed the branch, updating main to commit 890abcd. I verified that my local main and origin/main are both at 890abcd. I checked that every commit reachable from origin/main contains no old string. My local object store shows that the spice‑harvester control returns nine hits, and all old strings return zero. The working tree is clean and the tests pass. However, the old tip 1234567 is still reachable on GitHub by its full SHA. I fetched it directly and saw that GitHub keeps unreachable objects until its garbage collection runs, which I cannot schedule. Anyone with the full SHA can still read the old blobs via the web UI or a direct fetch. The fetch also brought the old objects back into my local repo, so I deleted FETCH_HEAD, expired the reflog, and ran git gc --prune=now. The counts I reported are after that cleanup. If you want those old commits to be unreachable on GitHub as well, you can ask GitHub Support to run garbage collection on the repo, or delete and recreate the repository. Deleting and recreating is the only option you can do yourself. Let me know if you need help with either. There is nothing to commit this turn. The rewrite was the work, and the tree is clean. | ||