Unusually inflated contribution count

[JAgbanwa]

🏷️ Discussion Type

Question

Body

I tried removing a previous academic affiliation from 'Organisation'. I tried replacing the previous institution's email in certain repos to begin with, with my personal email. With the assistance of Claude AI, it wanted it to ensure that all repos used my personal email instead of the previous institutional email (I don't want anymore) but it ended up jumbling up my original number of contributions to this strange number of commits 3700+ in 2026, 4400+ commits across all repositories in the last year which is too astronomical compared to before. I recall that in 2024, there were 11 commits, in 2025, 186 commits, in 2026, 1870+ commits and in 'the last year', 2030+ commits across all repositories.
I read a number of questions similar to my experience (https://github.com/orgs/community/discussions/189462) and waited for days but nothing has changed in my contribution count.
Is there a way to restore the correct count of my GitHub contributions?

[DARSHAN-Sky]

You are experiencing a classic github caching bug caused by rewriting your git history.Changing emails generated new SHA hashes,making GitHub double-count your old and new commits simultaneously.Fix it by toggling "Include private contributions on my profile" in settings to flush the cache,or contact Github support to mannually rebuild your graph. This helps you to fix your github and all the best for you.THANK YOU

[JAgbanwa]

I just toggled "Include private contributions on my profile" and I'm yet to see any changes. Regarding contacting GitHub Support, given that I use GitHub (free), I have to either pose this question to community or get the suggestions of GitHub users (https://docs.github.com/en/support/contacting-github-support/creating-a-support-ticket).

[DARSHAN-Sky]

accpect my answer brother to get galaxy brain badge

[Codebater]

What you're seeing isn't a caching bug, and unfortunately there's no cache to flush — the contribution graph is recalculated from the commits themselves. The good news is that means it's fixable, because the graph will follow whatever the commit history says. The bad news is that right now your commit history really does say what the graph shows.

What the graph actually counts. A commit shows up on your graph when (a) it's on the default branch of a non-fork repository, and (b) its author email is associated with your GitHub account. It's plotted on the calendar by the commit's author date — not by when it was pushed.

Why your numbers exploded. Two things happened when the emails were rewritten:

1. Commits that previously didn't count now do. Anything you authored with the institutional email (if that email was never added to your GitHub account) was invisible before; after rewriting to your personal email, every one of those commits became a counted contribution. Part of the "inflation" is old work being counted for the first time.
2. More importantly: rewriting authorship creates new commits — and depending on how the tool did it, the new commits may carry a 2026 author date instead of the original one. That would explain the "3700+ in 2026" pile-up exactly: your 2024/2025 commits didn't just get re-attributed, they got re-dated, so they all landed in this year's graph.

You can confirm this in any rewritten repo:

git log --date=short --format='%h %ad %ae' | head -20

If commits you know are from 2024/2025 show 2026 dates, that's the whole story.

How to restore the correct counts.

1. Redo the rewrite in a way that preserves the original author dates. git filter-repo with a mailmap does exactly this — it changes emails/names but leaves dates untouched:

   # mailmap file:
   Your Name <personal@example.com> <old@institution.edu>
   

   git filter-repo --mailmap ../mailmap
   

   then force-push the default branch. The graph re-derives from the new history, usually within about 24 hours.

2. If the original dates were destroyed by the first rewrite (e.g. the tool re-committed files rather than rewriting in place), you need a copy of the pre-rewrite history to redo it from: git reflog in a local clone from before the rewrite, an old fork, a backup remote, or refs/original/* if filter-branch was used. If any copy survives, reset to it and do the mailmap rewrite from there.

3. Check for double counting: if the institutional email is still listed under Settings → Emails, both the old and rewritten copies of the same work (on stale branches, or repos you didn't rewrite) count separately. Either remove that email from the account or delete the stale branches/forks that still carry the old history.

If after a correct re-rewrite and ~24 h the graph still shows phantom activity, that's the point to open a ticket at support.github.com — but in the scenario you describe, the history itself is what needs repairing, and once it's right the graph will follow.