Profile contribution graph still counts replaced commits after a squash

[siddhartha-yz]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

Profile

Body

After squashing commits and force-pushing the default branch of stickman-rl-lab on November 10, 2026, the July 31 cell on my profile increased from 81 to 117 contributions.

• The old main had 81 commits authored on July 31, 2026 (UTC+8).
• Current main (a32130e) has 39 on that date. Three SHAs are shared, so the other 36 are new.
• The displayed 117 matches 81 old commits plus 36 new SHAs. It looks as though the profile is still counting commits replaced by the squash. This is the profile calendar, not the repository Contributors graph.

The troubleshooting guide describes stale counts after rewriting history. Is there a supported way to refresh the profile contribution data so it counts only eligible activity, without rewriting the branch again?

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[kittimzhe]

Live-verified your numbers, and your arithmetic is right: the current history of stickman-rl-lab shows 39 commits in that July 31 (UTC+8) window — matching your post-squash count — while the profile cell shows 117 ≈ 81 (old, now-unreachable commits) + 36 (new squashed commits). I.e., the graph is counting the replaced commits as well as their replacements.

The mechanism, as best it's documented: the contribution graph is event-fed, not history-fed — a contribution is recorded when a commit is pushed to the default branch, and a force-push that replaces commits doesn't emit retraction events for the old ones. So after a squash, both generations remain counted until some recompute pass reconciles the graph with the live history. That's the same reason deleted-repo contributions can linger on profiles.

Practical expectations:

• Re-rewriting the history again won't purge the ghosts — it adds another generation of events.
• A recompute does reconcile this (the graph rebuilding to match actual history is the end state), but profile recomputation is exactly what's running multi-day-to-weeks behind during the [Incident]: Profile rendering issues affecting GitHub profiles #203416 incident. Your Nov 10 rewrite event is in that queue.
• If the cell still shows inflated numbers a couple of weeks after the incident backlog clears, that's the moment to register it in [Incident]: Profile rendering issues affecting GitHub profiles #203416 with your exact arithmetic — a cleanly-measured ghost-count case like this is easy for staff to verify internally.

[iheblaswd]

I can't verify the mechanism described in the reply above (event-fed counting, the recompute backlog, or the incident link), so I won't build on it. Some checks you can run yourself:

1. Check whether the replaced commits are still reachable. After a force-push, the old commits can still be reachable from other refs: other branches, tags, open or closed PRs, or a fork. Run git branch -a --contains <old-sha> and git tag --contains <old-sha> for a few of the 36 old SHAs that are no longer on main. If any ref still contains them, the profile may be counting them for that reason, and cleaning up those refs is the fix.
2. 2. Confirm the email on the commits. Contributions only count when the commit's author email is linked to your account and verified. Make sure the squashed commits use that email.
3. 3. Wait, then check again. Profile contribution data is not updated instantly after a history change. If the number doesn't change after a reasonable wait, contact GitHub Support with the old and new SHAs and the exact counts. That's the right route for a stale count.
      I can't confirm from here which of these applies to your repository.

[kittimzhe]

@iheblaswd's reachability check is exactly the right test — so I ran it, and it comes back clean:

The repository has exactly one ref: main. Zero tags, zero pull requests (so no refs/pull/* either), zero forks. Enumerated via the API just now. With a squash-rewrite onto main and no other ref in the repository, the replaced July 31 commits are unreachable from anything — there is no path left to them.

So both branches of the check now point the same way:

1. Empirically: unreachable commits are still counted on the profile (117 vs 39 in live history) — which is precisely the event-fed persistence described above, now confirmed rather than assumed.
2. By the documented criteria: contributions are counted from commits on the default branch. These commits left the default branch on Nov 10 — counting them contradicts the documented rule no matter where else they might be reachable.

For @siddhartha-yz nothing changes in the practical advice: don't re-rewrite (it adds another event generation), expect the recompute pass to reconcile the cell to ~39 eventually, and the incident backlog (#203416) is what's delaying that recompute right now.