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.

[Danielux135]

Reporting back as promised: this is fixed. Your pointer to the docs section turned out to matter a lot. I opened my reply to the ticket's closure email with it, so it read as a stale-data report rather than a git question, and this time a person picked it up. On 19 September Support ran cache clearance and garbage collection on the repository and rebuilt its contributions data, and the sidebar now lists only my account.

Full details, including what didn't work, are in my reply to queenofcorgis below. Thanks again.

[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.

[Danielux135]

Reporting back as promised: this is fixed, and your advice is pretty much what did it. I replied to the closure email for 4738157 instead of opening a new ticket, led with the docs link, and included the trailer search across every ref along with the /_sidebar vs /stats/contributors mismatch. Two days later a person from Support replied: they had run cache clearance and garbage collection on the repository and rebuilt its contributions data. The sidebar now lists only my account, and the orphaned a509f22d returns 422.

Your point about trailers versus authors was the turning point. Without it I'd still have been proving the wrong thing. Full details are in my reply to queenofcorgis below. Thank you.

[queenofcorgis]

Thank you for reporting this bug. We've been logging these posts and are currently investigating solutions. We will share updates as soon as work begins and we have a better sense of when it will ship.

In the meantime, we did publish a troubleshooting guide for folks who may have missing contributions if you haven't taken the steps outlined in this doc, I recommend doing those first.

We appreciate the patience!

[Danielux135]

Thanks for following up, and for logging these.

Closing the loop, since I said I'd report back: this is fixed. GitHub Support cleared it on 19 September, eleven days after the rewrite. Here's what didn't work and what did, in case it helps your investigation or the next person who lands here.

What didn't work

• Waiting. The docs give about 24 hours; the panel was still wrong eleven days later.
• Pushing. Ten pushes to the default branch after the rewrite didn't invalidate it.
• The first ticket (4738157), opened the same day. Cora, the virtual assistant, closed it within the same minute and pointed me to Docs and Community Discussions, since technical support isn't included on a free personal account.

Following the advice here, I didn't try another rewrite, a visibility toggle, a rename or filler commits.

What worked

Replying to Cora's closure email instead of opening a new ticket. In that reply I:

• led with the docs section on contributor data being stale after history changes, which names Support as the next step, so it read as a stale-data report rather than a git question;
• pointed out that two GitHub endpoints disagreed: /contributors and /stats/contributors returned only my account, while /_sidebar returned "contributorCount": 2, including claude;
• confirmed that no reachable commit carried the trailer, searching message bodies across every ref rather than just the author field;
• gave the SHA of the commit that had carried the trailer (a509f22d), which was unreachable from every branch but still resolved through the API.

Two days later a person from Support replied: they had run cache clearance and garbage collection on the repository and rebuilt its contributions data. After that, the sidebar listed only my account.

Today /_sidebar returns "contributorCount": 1, and a509f22d returns 422 "No commit found for SHA".

One thing that might be useful for the fix: the stale value was never in the contributor statistics, which were clean from the start, but in whatever backs the sidebar fragment. I can't tell which of the three steps did it, but my guess is the garbage collection, since the orphaned commit with the trailer was still being served until then.

[haXorFalcon]

The repository history appears to be fully clean based on the checks you’ve provided. Since the REST API, commit search, contributor data, and all branches already agree, while only the repository homepage sidebar still shows claude, this looks like a stale GitHub-side cache/index.

There doesn’t appear to be a user-facing way to manually refresh that specific Contributors sidebar. Since it has already been six days and there have been several subsequent pushes, I’d report it to GitHub Support specifically as a stale Contributors sidebar/index and ask them to refresh or reindex it.

I’ve seen GitHub’s contributor/statistics displays lag behind the underlying repository data before, so I’d expect this to be something GitHub needs to resolve on their side rather than anything remaining in your repository.

[Danielux135]

Thanks — you called it. It was a stale cache on GitHub's side, and nothing in the repository needed to change.

Support cleared it on 19 September: they ran cache clearance and garbage collection on the repository and rebuilt its contributions data, and the sidebar now lists only my account. What finally got a person to look at it was replying to the closure email of my original ticket instead of opening a new one. I've put the full details, including what didn't work, in my reply to queenofcorgis above, in case anyone else runs into this.