Contributors sidebar still shows a user with zero commits, six days after the history rewrite (REST API is already clean)

[Danielux135]

🏷️ Discussion Type

Question

Body

The right-hand Contributors panel on
https://github.com/Danielux135/Danielux135.github.io lists two contributors,
Danielux135 and claude. The claude account has zero commits in the
repository.

This is not a question about how to rewrite history or change commit
authorship — that is already done and verified. Every authoritative source
agrees the repository is clean, and only the sidebar disagrees. I am looking
for a way to get that cached index regenerated, or confirmation from someone
who has seen this resolve.

On 2026-09-08 a commit was pushed with an erroneous Co-Authored-By: Claude
trailer. It was removed the same day with git commit --amend and
git push --force-with-lease.

1. GET /repos/Danielux135/Danielux135.github.io/contributors → only
   Danielux135
2. GET /repos/Danielux135/Danielux135.github.io/commits?author=claude → []
3. GET /search/commits?q=repo:Danielux135/Danielux135.github.io+author:claude
   → total_count: 0
4. The orphaned pre-amend commit 57380992fdff362eaf9e0c258bdcc36c67d05669
   returns HTTP 422 "No commit found for SHA" — already
   garbage-collected on GitHub's side
5. /Danielux135/Danielux135.github.io/graphs/contributors-data → only
   Danielux135
6. git log --remotes --format='%an <%ae>|%s' | grep -i claude → no output
   across all three branches

Six days have passed, with pushes to the default branch on 2026-09-09, 09-10,
09-11 and 09-12. The statistics index regenerated correctly — item 5 above is
proof. Only the sidebar panel is stale, which suggests a separate index that
ordinary pushes do not invalidate.

• Support ticket: filed (4738157) and closed by a virtual assistant;
  technical support is not included on a free personal account.
• Toggling the repo private/public: would disable GitHub Pages on a free
  account and take my site down.
• Renaming the repo: impossible, the name Danielux135.github.io is the
  domain.

Is there any supported way to force the contributors sidebar index to
regenerate? Has anyone seen this particular panel eventually catch up on its
own, and after how long?

Thanks.

[ssdeniss]

GitHub now documents this exact situation under Contributor data is stale after history changes:

https://docs.github.com/en/repositories/viewing-activity-and-data-for-your-repository/viewing-a-projects-contributors#contributor-data-is-stale-after-history-changes

After a force-push, history rewrite, or deleted commit, contributor displays and repository statistics can take about 24 hours to refresh. If the contributor data is still incorrect after that, GitHub's supported next step is to contact Support. The documentation does not expose a repository-side cache invalidation or rebuild action.

Your API, commit-search, local-history, and /graphs/contributors-data checks show that the reachable Git history is already clean, so I would avoid another rewrite, visibility toggle, rename, or artificial commit. Include the repository URL, rewrite timestamp, removed SHA, and the clean API responses in the support request; that gives Support the evidence needed to escalate the stale UI index. Since you have already waited six days, this is past the documented refresh window.

[Danielux135]

Thanks for digging this up — I hadn't found that docs section, and it does describe exactly what I'm seeing.

One thing I should have said in the original post: I did open a ticket, on 2026-09-08, the same day it happened. It's 4738157. It was closed by Cora, the virtual assistant, pointing me back at Docs and Community Discussions, without a human ever looking at it. My account is a free personal one, so it's flagged as "technical support not included". So the documented next step is the one that already didn't work, which is why I ended up here.

That said, since posting I found something that I think changes what the ticket should say. Two GitHub endpoints are now disagreeing with each other about this repository:

• repos/Danielux135/Danielux135.github.io/stats/contributors returns a single entry, Danielux135, 240 commits. Clean.
• https://github.com/Danielux135/Danielux135.github.io/_sidebar returns "contributorCount": 2 and includes {"login": "claude"}. That's the endpoint that actually renders the panel on the repo home page.

So the stale value isn't in the contributor statistics at all — it's in whatever caches that sidebar fragment. That feels like a much more concrete thing to hand to Support than "my git history is clean", because it's their own data contradicting itself rather than me asking anyone to take my word for it.

I've also taken your advice on what not to do: no more rewrites, no visibility toggle, no rename, no filler commits. The rename isn't even possible here, since the repo name is the domain.

I'm going to reply to the closure email for 4738157 rather than open a new ticket, leading with the docs link and that endpoint mismatch. I'll report back here either way — if it works it might save the next person the six days.

Thanks again for taking the time.

[dellagattamichela]

GitHub documents this under Contributor data is stale after history changes. After a force-push or history rewrite, contributor displays can take about 24 hours to refresh, and if the data is still wrong after that, repository owners are told to contact Support. There's no documented way to force the refresh yourself, and at six days you're well past that window. So I'd skip any more workarounds and go straight to a ticket. Before you file it, though, it's worth running one more check.

Why your checks came back clean while the sidebar didn't: the sidebar picks up co-authors from Co-authored-by trailers, which is how claude got there in the first place. Most of what you checked only looks at the commit author:

• GET /repos/.../contributors counts authors only
• commits?author=claude and search/commits ... author:claude match the author field, not trailers
• graphs/contributors-data is also author-based
• git log --format='%an <%ae>|%s' prints the author and subject, while trailers are in the message body

So those results show that no commit was authored by claude, which was already true before the amend. They don't show that the trailer is gone everywhere. The 422 on the old SHA is the strongest evidence so far, but I'd still run a check that searches message bodies across every ref, including tags:

git fetch --all --tags
git log --all -i --grep='co-authored-by:.*claude' --format='%H %D %s'

If that prints nothing, you can tell Support that no reachable commit carries the trailer, which is a stronger statement than "no commits authored by claude." If it does print something, you've found what the sidebar is counting.

For the ticket, reply to the closure email for 4738157 instead of opening a new one. Start with a link to the docs section above, since it names contacting Support as the next step for exactly this situation. That makes it clear you're reporting stale data on GitHub's side, not asking for help with git, which is usually what gets tickets on free accounts closed by the bot. Then include:

• the repository URL
• the date of the rewrite (2026-09-08) and the removed SHA
• the fact that it's been six days, with several pushes to the default branch since
• your list of API and git checks, plus the result of the trailer search

That gives whoever picks it up everything they need to clear the cached entry.

[Danielux135]

This is the most useful thing anyone has told me about this, so thank you. The author-versus-trailer distinction is the part I had completely missed — you're right that every check I listed looks at the commit author, and the trailer lives in the message body, so I was proving something that was already true before the amend.

I ran what you suggested:

git fetch --all --tags
git log --all -i --grep='co-authored-by:.*claude' --format='%H %D %s'

No output. For completeness: the repo has 3 branches and 0 tags, and the removed commit isn't an ancestor of any of them (the compare API says "ahead" or "diverged" for all three). So I can now say that no reachable commit carries the trailer, which as you say is a stronger claim.

Two things came out of this that I think are worth writing down.

I'd been checking the wrong SHA. There were two commits with the trailer, not one. 57380992 was the local commit from before a pull --rebase, and it never reached GitHub — that's the one returning 422, and I'd been reading that 422 as "GitHub has already garbage-collected it". The one that actually got pushed is a509f22d, and repos/.../commits/a509f22d... still resolves today, nine days later. It's unreachable from every branch, but the object is still served. I don't know whether that matters to whatever builds the sidebar index, but it seemed worth mentioning given your point about what the sidebar is actually counting.

The stale data has a specific home. repos/.../stats/contributors returns only Danielux135 (240 commits), but https://github.com/Danielux135/Danielux135.github.io/_sidebar — the endpoint that renders the panel — returns "contributorCount": 2 with {"login": "claude"} in it. Two GitHub endpoints disagreeing about the same repository. That's now the centrepiece of what I'm sending.

On the ticket: I'm taking your advice about replying to the closure email for 4738157 instead of opening a new one, and leading with the docs link so it reads as a stale-data report rather than a git question. For what it's worth, your guess about the bot was right — 4738157 was closed by Cora without a human seeing it, and my account is marked "technical support not included", so I suspect the framing matters more than usual here.

I'll post back with whatever happens. Thanks again.