The first GitHub repository to reach 100,000,000 commits.
Warning: Cloning this repository is not recommended. See Verifying the Commit Count for details.
This repository exists purely as a technical experiment and record attempt. It explores the absolute limits of Git's pack format and the Smart HTTP protocol. No animals, servers, or rate limits were intentionally harmed in the process. Results may vary. Side effects may include mass confusion on your GitHub profile.
Pure Python CLI that writes Git pack files directly - no git binary, no subprocess, no GitPython. ~80 bytes per commit via REF_DELTA encoding. ~49,000 commits/second.
- Writes
.pack+.idxfiles directly (Git pack format v2) - Every commit is a valid git object -
git fsck --fullpasses - All commits use the empty tree SHA-1 (no blob/tree needed)
- REF_DELTA encoding - only the 40-byte parent SHA changes
- Delta chain depth capped at 50 (git's default) so
index-packcan resolve chains in parallel - Fixed timestamp (1970-01-01), fixed message (
COMMITMENT) - Auto-pushes via Smart HTTP between batches
Why Smart HTTP instead of git push?
git push spawns pack-objects which re-enumerates all objects (O(n)), discards existing deltas, and recomputes them (O(n²)). Commitment streams pre-built packs directly to the server - the server runs index-pack (O(n)) instead, skipping all of that.
git push |
Smart HTTP | |
|---|---|---|
| Delta computation | O(n²) recomputation | None (pre-built) |
| Object enumeration | Full graph walk | None |
| 500k commits | Minutes of CPU | Seconds (I/O only) |
| Metric | Value |
|---|---|
| Throughput | ~49,000 c/s |
| Bytes/commit (pack) | ~80 |
| Bytes/commit (pack + idx) | ~108 |
| Pack size at 100M | ~7.5 GB |
| IDX size at 100M | ~2.6 GB |
| Total at 100M | ~10.1 GB |
| Generation time | ~34 min |
| Approach | B/commit | 100M |
|---|---|---|
| Naive (3 obj, unique msg+ts) | ~450 | ~42 GB |
| Full obj, no REF_DELTA | ~150 | ~14 GB |
| Commitment | ~80 | ~7.5 GB |
| Prior art (CommitHoarder) | ~165 | ~15.3 GB |
April 16, 2026, 20:17 - 23:53 UTC+2 -- 3 hours, 35 minutes, 38 seconds.
50 batches of 2,000,000 commits each, totaling 99,999,999 commits pushed to GitHub.
Local generation was remarkably stable: consistently ~41 seconds per batch, yielding ~48,700 commits/second. The only outlier was batch 35 at 49.3s -- likely a brief system hiccup. Total generation time: 2,051 seconds (34 minutes).
The lion's share of the time was consumed by GitHub's server-side index-pack process: 10,887 seconds (181 minutes), accounting for 84% of the total runtime. Push time increased steadily from 73s on the first batch to 338s on the last -- a 4.6x factor, because GitHub re-indexes the entire growing history with each new batch.
| Metric | Value |
|---|---|
| Total data transferred | 8.14 GB |
| Avg. pack size / batch | 162.8 MB |
| Effective upload rate | ~0.7 MB/s |
| Generation time | 2,051s (16%) |
| Push / index-pack time | 10,887s (84%) |
| Total wall time | 12,938s |
The upload rate was limited by GitHub's processing speed, not by bandwidth.
The full run log with per-batch timings is available at doc/run_2026-04-16_18-17-31.log.
uv syncCopy .env.example to .env and add a Fine-Grained Personal Access Token with Read and Write access to Code for the target repository.
uv run python src/cli.py init --total 99999999 --branch master
uv run python src/cli.py run
uv run python src/cli.py statusAs of April 2026, GitHub does not display the total commit count for this repository. A full clone works, though:
This screenshot was taken before the final commit that added this README and the source code to the repository.
Warning: Cloning will download ~5.8 GB of pack data containing 100,000,000 objects and take a long time to resolve ~98M deltas. If you just want to look at the source code, use the mirror without the 100M commits: Wuerfelhusten/no-commitment
Linux: Expect ~5 minutes for the download and another ~10-30 minutes for delta resolution, depending on your hardware. A full clone took ~20 minutes on an NVMe Gen 4 drive (WSL/Ubuntu).
Windows: The clone does not work. Git for Windows fails with an out-of-memory error caused by heap fragmentation when resolving the deltas, exhausting its address space long before physical RAM runs out.
git clone https://github.com/Wuerfelhusten/commitment.git
cd commitment
git rev-list --count HEADAfter cloning, git rev-list --count HEAD walks the entire chain and prints the exact commit count.
To additionally verify object integrity:
git fsck --fullMIT - Copyright (c) Modding Forge

