Contribution graph inflated after force pushes - needs cache reset

[himanshuraj108]

My contribution graph is showing 5,580 contributions
when the real count should be ~1,830 for 2026.
Individual days also show ~3x the real count
(e.g. one day shows 907 instead of real 298).

This happened after multiple force pushes on Aug 14, 2026.

I have waited 12+ hours and tried private→public toggle
on all repos — issue persists.

Username: himanshuraj108

Repos affected:

• himanshuraj108/LMS
• himanshuraj108/sharedexpensesapp
• himanshuraj108/vertex-crm
• himanshuraj108/splitwiseclone

Please reset/recalculate my contribution graph cache.

[harybenzin7]

That definitely sounds like a contribution cache issue; hopefully GitHub can recalculate it soon. 1947game is also worth checking out for a smooth experience.

[hoangperry]

Unfortunately this isn't something you (or anyone in this forum) can trigger — some context on why the toggles didn't help:

The contribution graph is event-based. When you force-push rewritten history, every rewritten commit is a new commit object (new SHA, same author date), and commits that were previously counted don't automatically fall out the moment they become unreachable — de-duplication only happens when the backend recalculates, which is tied to periodic maintenance rather than anything user-facing. That's why the counts inflated by roughly the number of rewrites and why 12 hours plus visibility toggles changed nothing.

Two things worth knowing:

1. It usually self-corrects, but on the scale of days to weeks (when unreachable objects get cleaned up and the graph is recomputed), not hours.
2. The only way to force a recalculation is a support ticket: https://support.github.com/contact — account-specific cache/graph resets are exactly the kind of request GitHub staff redirect from this forum to Support. Include what you posted here (real vs shown counts, the four repos, the Aug 14 force-push date); it's a clean, verifiable request.

One preventive note: squash-rebases and force-pushes on branches that were already counted will do this again — if the history rewrite was about removing sensitive data it's unavoidable, but for routine cleanup, merges into the default branch keep the graph stable.