Optimizing reference deletions in Git
Comments on “Optimizing reference deletions in Git”
Claim-checked. Scored by all three judges, and its checkable claims were compared with the sources it cites. How far stories are checked
A GitLab engineer describes how Git's files backend rewrites the entire packed-refs file on every packed reference deletion, which gets slow in repositories with millions of refs. While benchmarking a Rust reimplementation, they found the C version needlessly reformatted unchanged entries.
Why it ranked
No. 26 of 46 with a score of 0.60. The panel rated it highest on new information (0.90) and substantiated (0.88), lowest on significance (0.48). Placed No. 26, No. 20 by score alone: the sixth Programming & dev tools story of the day (−0.060). The placement terms move stories; they are not part of the score.
- AI judgeJudge 2claude-haiku-5-5
- Concrete, measured engineering write-up on Git reference deletion performance with benchmarks and a merged patch. Useful to developers, narrow audience, mostly a niche infrastructure topic.
- AI judgeJudge 3gpt-5.6-luna
- A well-supported engineering write-up explains Git’s packed-reference deletion bottleneck, provides implementation details, benchmarks, and a merged optimization. It is highly relevant to Git and repository-scale infrastructure, though its direct audience is narrower than all technology builders.
Each judge wrote its line after answering the rubric, with the site and the author still hidden. Every answer behind this is in the table under Score.
Score
0.60total under rubric v2.3
- Significance0.48
- Reader interest0.72
- Audience breadth0.51
- Practical relevance0.58
- Substantiated0.88
- Technical depth0.87
- New information0.90
- Counts against: Promotional0.04
- Counts against: Overclaim0.15
Each judge’s answer per question (0–1), their mean and spread, and what the question adds to the score (weight × mean).
| Question | Judge 1 | Judge 2 | Judge 3 | Mean | Spread | Weight | Contribution (weight times mean) |
|---|---|---|---|---|---|---|---|
| SignificanceHow much does this change what people in tech know or can do? | 0.51 | 0.30 | 0.62 | 0.48 | 0.32 | +0.24 | +0.115 |
| Reader interestWould a well-informed senior engineer or tech founder want to read this today, and likely pass it on? | 0.62 | 0.72 | 0.82 | 0.72 | 0.20 | +0.26 | +0.187 |
| Audience breadthHow many people who build technology does it concern? | 0.55 | 0.45 | 0.52 | 0.51 | 0.10 | +0.13 | +0.066 |
| Practical relevanceHow useful is it to someone who builds software or tech products? | 0.57 | 0.50 | 0.66 | 0.58 | 0.16 | +0.22 | +0.127 |
| SubstantiatedHow well is it backed? Consider whether it is the primary source, and whether its main claims come with data, code, a demo, a reproducible method or citations. | 0.93 | 0.80 | 0.90 | 0.88 | 0.13 | +0.05 | +0.044 |
| Technical depthHow technically substantive is it? | 0.99 | 0.80 | 0.82 | 0.87 | 0.19 | +0.05 | +0.044 |
| New informationDoes it contain information absent from the stories covered in the last 7 days (list provided)? | 0.83 | 0.90 | 0.98 | 0.90 | 0.15 | +0.05 | +0.045 |
| PromotionalIs it mainly marketing with little substance (a press release, ad or sponsored post with no real information)? A launch post that carries real news is not promotional. | 0.05 | 0.05 | 0.02 | 0.04 | 0.03 | −0.19 | −0.008 |
| OverclaimDo the headline or conclusions claim more than the body supports? | 0.21 | 0.20 | 0.03 | 0.15 | 0.18 | −0.11 | −0.016 |
| Sum of contributions | +0.603 | ||||||
| Claim-check penalty | 0.000 | ||||||
| Total, as published | 0.603 | ||||||
Spread is the highest minus the lowest judge answer. marks a spread above 0.40: the judges disagree, and the story is marked contested.
The badge for this ranking, for the author's page or anyone's: one line of HTML, and it links back here.
<a href="https://rubric.hrih.si/editions/2026-11-09/26/"><img src="https://rubric.hrih.si/badge/2026-11-09/26.svg" alt="Ranked #26 on Rubric, 9 Nov 2026" width="238" height="28"></a>Claim check
Claim check: 1 matches source · 3 no source given · 4 couldn’t check. Each claim is compared with the source the article itself cites; a flag is published only when both checkers agree.
Matches sourceVersion
The files backend was the only reference storage backend in Git until Git 2.45, which introduced the reftable backend.
The cited source says the same thing.
The article says “The files backend was the only backend for storing references until Git 2.45. The release saw the introduction of the newer and better reftable backend”
The source says “Git v2.45.0 introduces a new "reftable" backend, which uses a new binary format to store references”
Source cited by the article: about.gitlab.com/blog/whats-new-in-git-2-45-0
Couldn’t checkVersion
The reftable backend will be the default reference backend in Git 3.0.
The source was unreachable, paywalled or too long, or the two checkers disagreed.
The article says “the newer reftable backend here, which will be the default in Git 3.0”
The source says No passage could be compared.
Source cited by the article: about.gitlab.com/blog/whats-new-in-git-2-45-0
Couldn’t checkNumber
GitLab's gitlab repository contains over 15M references.
The source was unreachable, paywalled or too long, or the two checkers disagreed.
The article says “GitLab's gitlab repository contains over 15M references”
The source says No passage could be compared.
Source cited by the article: gitlab.com/gitlab-org/gitlab
Couldn’t checkDate
Git introduced the packed-refs format in 2006, in a commit by Linus Torvalds.
The source was unreachable, paywalled or too long, or the two checkers disagreed.
The article says “Git introduced the notion of packed-refs back in 2006”
The source says No passage could be compared.
Source cited by the article: gitlab.com/git-scm/git/-/commit/e1e22e37f47e3f4d741d28920e1d27e3775c31ad
No source givenBenchmark result
In the article's benchmark with 100000 refs, the Rust files-backend version deleted a ref 17.7% faster than Git v2.56.0 (30.6 ms vs 37.1 ms mean wall time).
The article gives no link or citation for it.
The article says “Wall Time 30.6 ms ± 1.7 ms 28.4 ms … 35.4 ms -17.7%”
The source says No source to compare with.
No source givenBenchmark result
Writing unmodified packed refs verbatim with fwrite() instead of rebuilding them with fprintf() and oid_to_hex() cut deletion wall time by about 17.4% (66.5 ms to 54.9 ms), comparable to the Rust version.
The article gives no link or citation for it.
The article says “That's an 18% improvement in raw speed while deleting references and comparable performance to the Rust version”
The source says No source to compare with.
No source givenCausal conclusion
The C implementation was slower because it needlessly reformats unmodified references via write_packed_entry() when rewriting packed-refs.
The article gives no link or citation for it.
The article says “it calls write_packed_entry(). The function rebuilds the information with fprintf() and oid_to_hex(). This is simply unnecessary, since there were no modifications made to the reference”
The source says No source to compare with.
Couldn’t checkDate
The patch has been merged into Git master and will be part of Git v2.98, with Git 3.0 following two releases later.
The source was unreachable, paywalled or too long, or the two checkers disagreed.
The article says “It's now merged into master: fc70f528aa1927012538052014d7ea784b5a38fa and will be a part of Git v2.98”
The source says No passage could be compared.
Source cited by the article: gitlab.com/git-scm/git/-/commit/fc70f528aa1927012538052014d7ea784b5a38fa
Also covered by
No other coverage was clustered with this story.
Elsewhere
Elsewhere: HN 2 pts, not on front page
Recorded for context only, checked 9 Nov 2026, 05:46 UTC. It played no part in the ranking.