Commit numbers in Contribution activity history unmatching after working with git-filter-repo #205568
🏷️ Discussion TypeQuestion BodyThe commit numbers in Contribution activity on my Overview page do not match with the actual commits of certain repos after my attempt to change the e-mail address of all the commits. To be honest, I wasn't strictly precise when I was running CLI commands in my bash terminal. I ran commands like these: This is a portion of* the result when I run the command I click on commits in Contribution activity of my repo like scibx-bookmarks. I see the message 'No commits history'. These are examples of mismatching commits history: August 2026 June 2026 April 2026 March 2026 October 2025 September 2025 I'm pretty sure there are more cases like these. What is wrong with my Contribution activity history? |
Replies: 3 comments
|
Hey @theplenoh Please Mark this as answered if this helps you Nothing is broken, and no history was lost. What you're seeing is two different data sources disagreeing:
Your The optimistic partThe counts in your graph are the higher of the two numbers, and GitHub does not retroactively delete contribution records. You're not losing green squares — the drill-down link is just stale. Your actual repos are intact; confirm with: git rev-list --count HEAD
git log --format="%an <%ae> | %cn <%ce>" | sort -uIf that output shows only your intended identity, the rewrite succeeded and the job is done. What's worth actually fixing1. Verify every email, including the old ones. 2. Check the default branch actually matches what you pushed. git branch -a
git symbolic-ref refs/remotes/origin/HEADagainst repo Settings → Branches. A leftover 3. Confirm the repos aren't forks. Commits in forks don't count toward contributions at all. 4. Stop rewriting. Every additional 5. If you want the numbers to genuinely reconcile: contact GitHub Support. They can request a rebuild of the contribution index for an account. This is the only real lever — there is no user-facing way to force it, and empty commits won't trigger it. Explain that you rewrote history with The one thing to double-check before you relaxCompare local and remote commit counts per repo: git rev-list --count HEAD
git rev-list --count origin/mainIf those match, you're fine — the mismatch is purely cosmetic index drift. If local is higher, one of those force-pushes truncated the remote, and you'd want to recover from |
|
Hi @theplenoh Core Technical Cause
Recommended Solution
git rev-list --count HEAD
git rev-list --count origin/main
|
|
Hey @theplenoh, Don't worry, your actual commit history and repositories are fine. What you're seeing is a classic cache desync between GitHub's contribution graph index and the newly rewritten Git history. Here is what's happening behind the scenes and how to sort it out:
|
Hey @theplenoh
Please Mark this as answered if this helps you
Nothing is broken, and no history was lost. What you're seeing is two different data sources disagreeing:
/<repo>/commits?author=theplenoh&since=…&until=…, restricted to the repo's current default branch.git filter-reporewrites every commit, so every SHA changes. The old commits become unreachable the moment you force-push. The index still remembers "4 commits in August…