How does GitHub determine which commits are included in the Contributors graph after a history rewrite?

[MrOptor]

🏷️ Discussion Type

Question

💬 Feature/Topic Area

Code Search and Navigation

Body

I've been looking into how GitHub calculates repository contributor statistics, particularly after a repository's history has been rewritten or migrated.

If a commit remains reachable from the default branch and is correctly attributed to a GitHub account, what determines whether GitHub includes that commit in the Contributors graph?

I'm especially interested in how GitHub handles cases where the commit existed before a migration but the repository's object history or branch references changed afterward.

Is the contributor graph calculated directly from the current Git object history, or is there some separate statistics/indexing process involved?

[MrZoic]

From what I understand, the Contributors graph isn't simply a list of every commit that exists in the repository.

GitHub calculates contributor statistics from the repository's current history, with the default branch being particularly important. So after a migration or history rewrite, a commit can still exist and be correctly attributed to a user without necessarily being reflected in the contributor statistics immediately.

I don't think GitHub publicly documents the exact internal indexing process behind the Contributors graph, so I wouldn't assume it's just reading the Git object database directly on every page load.

For a migrated repository, I'd first check that the commit is reachable from the current default branch and that it isn't a merge/empty commit. If those checks pass and the statistics still don't match, I'd suspect the contributor statistics/index hasn't caught up with the changed history rather than the commit attribution itself being wrong.

[tushar240907]

From what I understand, the Contributors graph isn't simply a list of every commit that exists in the repository.

GitHub calculates contributor statistics from the repository's current history, with the default branch being particularly important. So after a migration or history rewrite, a commit can still exist and be correctly attributed to a user without necessarily being reflected in the contributor statistics immediately.

I don't think GitHub publicly documents the exact internal indexing process behind the Contributors graph, so I wouldn't assume it's just reading the Git object database directly on every page load.

For a migrated repository, I'd first check that the commit is reachable from the current default branch and that it isn't a merge/empty commit. If those checks pass and the statistics still don't match, I'd suspect the contributor statistics/index hasn't caught up with the changed history rather than the commit attribution itself being wrong.