Contribution graph double-counting commits after a history rewrite

[Sxy623]

🏷️ Discussion Type

Question

Body

Hi everyone,

After rewriting commit history and force-pushing to the default branch of a private repository, my profile contribution graph appears to count the affected commits twice.

The rewrite only changed one older commit message. The author and committer information, including both timestamps, was preserved. No extra commits were added, and the old history was not pushed to another branch or tag.

The force-push happened on October 26, 2026, and the duplicate counts are still visible.

I contacted GitHub Support, but my ticket was closed because the support options available to my account are self-service resources.

Has anyone experienced this? Did the contribution graph eventually correct itself, and is there a recommended way to request a recalculation?

Since the repository is private, I’d prefer not to share its details publicly. Any guidance would be appreciated. Thank you!

[shivyadav11]

Hi! I haven't done a history rewrite myself, so I can't share a personal fix, but I looked through several similar threads and thought a summary might help.

What seems to be going on: when you force-push rewritten history, the rewritten commits get new SHAs, and a few people report that the old, now-unreachable commits are not removed from the contribution graph straight away. One reply in this thread explains that the cleanup depends on a backend recalculation that users cannot trigger: https://github.com/orgs/community/discussions/204915

Some points that came up in those threads:

1. Timing is unclear. A few people waited more than 24 hours with no change, and I could not find an official statement about how long the graph takes to correct itself. Your push was only on October 26, so it may be worth giving it a few more days before assuming it is permanently stuck.

2. Toggling "Include private contributions on my profile" is suggested by some, but in at least one thread it did not change anything, and another reply says there is no cache to flush. I would not rely on it.

3. Another user had the same situation with a closed ticket because their account only had self-service support: https://github.com/orgs/community/discussions/207602. So you are not the only one.

4. As a prevention tip from other replies, rewriting commits before they are pushed avoids this problem, though that is obviously no help once the push has happened.

Sorry I can't give you a definite answer. If it is still wrong after a few days, replying on that thread or tagging GitHub staff in a discussion may be the best way to get it noticed.

Hope it gets sorted soon!

[MuhammadShayan8401]

Hi! One possibility is that GitHub's contribution data hasn't fully caught up with the rewritten history yet. Since the force-push happened only recently, I'd give it a few more days to see whether the duplicate counts disappear on their own.

I'm not sure whether GitHub automatically reconciles contributions from unreachable commits after a history rewrite, but it seems worth waiting before assuming the issue will persist. Hopefully, someone who has experienced the same situation can confirm whether this resolves itself over time.

[mohamed-safras]

Hi @shivyadav11

What you're describing can happen after a history rewrite and force-push, especially when contribution data has already been indexed. Contribution graphs are generated from repository activity and may not always update immediately after rewritten history is pushed. There can be a delay before contribution statistics are recalculated and reflected on your profile.

Since the author and committer information were preserved and no additional commits were intentionally introduced, I'd give it some additional time to see whether the graph self-corrects. GitHub's contribution data is processed asynchronously, and profile statistics are not always updated in real time.

Unfortunately, there isn't a public mechanism to manually trigger a contribution graph recalculation. If the issue persists after a reasonable period, the only available route would be to contact GitHub Support again, although support options may vary depending on the account's support entitlements.

As this repository is private, it's understandable that you wouldn't want to share specific details publicly. Other community members who have performed history rewrites on private repositories may be able to share whether their contribution counts eventually reconciled on their own.

It would be interesting to hear if anyone else has observed duplicate contribution counts persisting for more than a few days after a force-push that only rewrote existing commits.

[shivyadav11]

Thanks for the detailed explanation! I agree that waiting a little longer makes sense, especially since there doesn't seem to be a public way to trigger recalculation manually. Hopefully, others who have experienced this can share whether their contribution graphs eventually corrected themselves...

[NexzaDev]

Hi @Sxy623,

I haven't found any documented way for a user to trigger a recalculation of the contribution graph, so I can't promise a fix, but here is what I found and one way to make your report much easier to act on.

1. You're not the only one

Several recent threads describe the same pattern, where old commits stay counted after a rewrite and force-push, for example #207780 and #208282, plus the ones already linked above. In #208282 a reply states that these reports are being logged and investigated. I can't verify who wrote that reply or give a timeline, but it suggests the behaviour is known rather than specific to your account.

2. Measure what GitHub is counting (read-only)

You can ask the GraphQL API what is behind the number for the affected days, without changing anything. With the GitHub CLI:

gh api graphql -f query='
query {
  viewer {
    contributionsCollection(from: "2026-10-25T00:00:00Z", to: "2026-10-28T00:00:00Z") {
      totalCommitContributions
      restrictedContributionsCount
      commitContributionsByRepository(maxRepositories: 10) {
        repository { nameWithOwner isPrivate }
        contributions(first: 20) {
          nodes { occurredAt commitCount }
        }
      }
    }
  }
}'

Compare commitCount per day and repository with what git log --author=<you> --since=... --until=... shows on the current default branch. If the API count is higher than the number of reachable commits, that's concrete evidence of stale contribution records, which is exactly what GitHub would need to see. Adjust the dates to cover the days with duplicates. Private-repository activity only appears in your profile if "Include private contributions on my profile" is enabled.

3. What I'd do (and not do) in the meantime

• Give it a few more days before treating it as permanent. Your force-push was only a day ago, and other reports describe delays of days, although I couldn't find an official timeline.
• Don't rewrite or force-push again to "force" a refresh, and don't push the old history to a branch or tag. Another change can make the state harder to explain.
• Toggling the private-contributions setting or changing repository visibility is sometimes suggested, but others report it made no difference, so I wouldn't count on it.

4. Getting it to GitHub

Since the ticket was closed with a pointer to self-service resources, it may be worth replying to that ticket (or opening a new one) with the evidence from step 2: the date and time of the force-push, the repository name (which you can share privately with Support), the SHAs before and after the rewrite if you have them, the number your profile shows versus the number of reachable commits, and the GraphQL output with anything sensitive removed. A short, factual report like this is easier for a human to triage than a general description. You can also add the same numbers to one of the existing threads, so staff can see the pattern across reports.

I hope it corrects itself soon, and please post an update if it does.