docs: CONTRIBUTORS.md published numbers its own command did not print - #159
Merged
Conversation
The AI-assistance block advertised "382 of 511 commits" beside a `git log` invocation that prints neither figure, and the maintainer, dependabot and github-actions counts were wrong the same way. The counts were taken across every ref rather than `master`. This clone carries a `backup-pre-rewrite` branch and a `refs/original/` backup from the July history rewrite, holding a second copy of 116 commits, plus around twenty stale local branches, none of it pushed. So the numbers were not merely inflated, they were impossible for anybody else to reproduce: a reviewer running the published command on their own clone gets 414, not 511, with nothing to explain the gap. 382 was also a sum of trailer lines rather than a count of commits, and seven commits carry two trailers. Everything is now counted on `master` with the command that prints it, and the `.mailmap` comment is rewritten: it still claimed to fold a placeholder identity that the rewrite removed from `master` months ago. The correction is recorded in the file rather than quietly applied. This project tells everyone else that a published number should come from a command they can run, and this was the one file where that was untrue. It surfaced while re-verifying figures for a grant application that cites this file as evidence. Commit counts move with every commit, so they are stamped with a date rather than pinned by a test, which would fail on the next merge. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The defect
CONTRIBUTORS.mdadvertised 382 of 511 commits beside agit loginvocation that prints neither number. The maintainer count of 486, dependabot
at 20 and
github-actions[bot]at 4 were wrong the same way.Three separate errors, and the first is the one that matters:
Counted across every ref rather than
master. This clone carries abackup-pre-rewritebranch and arefs/original/backup from the July historyrewrite, which together hold a second copy of 116 commits, plus around twenty
stale local branches. None of it is pushed. So the figures were not merely
inflated, they were impossible for anybody else to reproduce. A reviewer
running the published command on their own clone gets 414, not 511, with nothing
to explain the gap.
382 was a sum of trailer lines, not a count of commits. Seven commits carry
two trailers, so the two numbers differ and the sentence said commits.
The
.mailmapcomment was stale. It described folding a placeholderyour-email@example.comidentity that the rewrite removed frommastermonthsago. The mailmap still earns its place for the two spellings of the maintainer
name, but not for the reason it gave.
Two smaller ones: the near-miss test count in the
@hvadlamani1entry saidthree where the PR has two, and
github-actions[bot]has zero commits onmaster.What changed
Everything is recounted on
masterwith the command that prints it: 395 of 414maintainer commits, 264 of 414 carrying a trailer, 271 trailer lines.
The correction is written into the file under "A correction" rather than quietly
applied. This project tells everyone else that a published number should come
from a command they can run, and this was the one file where that was untrue. It
surfaced while re-verifying figures for a grant application that cites this file
as evidence.
Also adds an "In flight" section crediting @kkkhs and @hossainzarif23,
including #140, which was finished work closed unmerged with the CLA as the
blocker. That is a cost this process imposes on the contributor rather than a
shortcoming of the contribution, and it should not vanish from the record.
Why no test
Unlike the corpus counts in the README, commit counts move with every commit, so
a test pinning them would fail on the next merge. They are stamped with a date
instead, and the command sits beside each one.
Checks
Docs only. Nothing frozen is touched and the fingerprint is unchanged at
15846a0915769d4a, so the dogfood clock is unaffected. Claims guards pass.