Contributors sidebar differs from audited main history: safe way to refresh?

[henri-ralmeida]

🏷️ Discussion Type

Question

Body

I maintain https://github.com/henri-ralmeida/prumo. Its repository sidebar shows two contributors, henri-ralmeida and JrSantiaggo, but I cannot find a matching commit attribution for JrSantiaggo in the current default branch. I would like to understand the discrepancy and refresh the calculated list if it is stale.

Checks made on October 9, 2026:

• Default branch: main. All 267 commits returned by the GitHub commits API have author.login and committer.login set to henri-ralmeida.
• None of those commit messages contains a Co-authored-by trailer. Filtering the main commit history by author=JrSantiaggo returns an empty list.
• HEAD at the time of the check: 7a115e8e9bad45abe710977f53eaf6fa5a7c4890.
• The root commit, 6a24817289411b765cf08a3bd045bfd4950e4b98, is authored by Henrique and has no parents. Its message records the import of graph-foreman under the MIT license.

Prumo retains the original project credit and MIT attribution. I want to preserve that credit and the current Git history; this question concerns the automatically calculated Contributors sidebar. I do not have a verified timestamp for any past history rewrite, so I am not claiming that a particular cache timeout has elapsed.

I read the pinned guide https://github.com/orgs/community/discussions/209302 and the related report https://github.com/orgs/community/discussions/206602. The pinned guide includes reports that renaming the default branch and renaming it back refreshed the list. I have not tried that workaround.

Is there a supported way to request or trigger a recalculation without renaming main or affecting CI, pull requests, and integrations? Are there other attribution sources I should inspect before concluding that this is stale data?

[beenish-majeed]

Based on the checks you've already performed, stale or inconsistent contributor data is a plausible explanation, but I would verify the other contributor views before treating it as the confirmed cause.

You've established that all 267 commits returned by the commits API on main identify henri-ralmeida as both author and committer, that no commit message contains a Co-authored-by trailer, and that filtering the commit history by JrSantiaggo returns no results. That is useful evidence that the current default-branch history does not explain the extra sidebar entry.

1. Compare the contributor views

I would check these three sources and record what each one shows:

• Repository homepage: Does the sidebar still list JrSantiaggo?
• Insights → Contributors: Does the contributor graph also list that account? You can open the [contributors graph](https://github.com/henri-ralmeida/prumo/graphs/contributors) directly.
• REST API: Compare the results from the [repository contributors endpoint](https://api.github.com/repos/henri-ralmeida/prumo/contributors) with the current commit history.

This comparison is important because a discrepancy confined to the homepage sidebar would suggest that the sidebar's displayed data is not in sync with the other views. It would not, by itself, prove exactly which internal cache or indexing process is responsible.

GitHub's documentation for [viewing a project's contributors](https://docs.github.com/en/repositories/viewing-activity-and-data-for-your-repository/viewing-a-projects-contributors) explains how the contributor graph is calculated and notes that contributor data can be stale after history changes.

2. Check the remaining attribution sources

Before concluding that the sidebar is stale, I would also check:

• The author name, author email, committer name, and committer email in the actual commit metadata, rather than relying only on the displayed GitHub usernames.
• Whether any commit messages contain co-author trailers or other attribution information that might have been overlooked.
• Whether the contributor graph and API agree with each other, and whether the discrepancy is confined to the homepage sidebar.
• Whether there is evidence of a previous history rewrite, deleted commits, or other historical changes that could explain an outdated calculation.

The imported project's MIT license and copyright notices should be preserved, but they do not, on their own, establish GitHub commit authorship. Conversely, the absence of JrSantiaggo from the current commit history does not establish whether that person contributed to the original upstream project.

Given the checks you've described, I would not rewrite the history or change attribution just to make the sidebar match.

3. Request a refresh without renaming main

GitHub's documentation states that after force-pushing, rewriting history, or deleting commits, repository contributor displays and statistics can take approximately 24 hours to refresh. If the data remains incorrect after that period, repository owners are directed to contact [GitHub Support](https://support.github.com/).

Since you do not have a verified timestamp for a history rewrite, I would avoid assuming that the documented waiting period has already elapsed.

I also would not rename main and then rename it back as the first troubleshooting step. Although users have reported that this workaround refreshed contributor displays, it changes repository configuration and may affect collaborators, pull requests, CI, or integrations. It is not a documented, general-purpose contributor-cache refresh mechanism.

Instead, I would:

1. Record the current state of the homepage sidebar, contributors graph, and REST API.
2. Confirm whether those views disagree.
3. If the discrepancy persists, ask GitHub Support or a GitHub staff member in this discussion to inspect or refresh the contributor data for the repository.

Include the repository URL, the default branch, the HEAD SHA you recorded, the date of your checks, and the results from each contributor view. Explain that you want to preserve the current history and existing license attribution and are looking for a refresh that does not require changing repository configuration.

Conclusion

Your checks provide good evidence that JrSantiaggo cannot currently be matched to a commit in the reported main history. They do not establish why the account remains in the sidebar.

The least disruptive next step is to compare the homepage sidebar, Insights contributor graph, and contributors API, then request GitHub's assistance if the discrepancy persists. That preserves the repository's history and attribution while giving GitHub enough information to investigate the displayed contributor data.

[henri-ralmeida]

Thanks for suggesting this comparison. I checked the views on October 9, 2026, at about 14:52 UTC:

• Repository homepage sidebar: 2 contributors, henri-ralmeida and JrSantiaggo.
• Insights → Contributors with Period set to All: only henri-ralmeida, with 267 commits: https://github.com/henri-ralmeida/prumo/graphs/contributors?all=1
• The audited main history still has 267 commits, all associated with henri-ralmeida as both author and committer, with consistent underlying author/committer metadata and no Co-authored-by trailers. HEAD remained 7a115e8e9bad45abe710977f53eaf6fa5a7c4890.
• I could not independently inspect the REST contributors endpoint because the environment used for the check restricts access to it. That is a limitation of this check, not evidence that the GitHub endpoint is broken or returns an empty list.

This confirms a discrepancy between the sidebar and the Insights graph/current main history. It makes stale sidebar data more plausible, but does not establish the internal cause. I have not renamed the branch or rewritten history.

Is there a safe way to request a recalculation while keeping main, commit history, CI, pull requests, and integrations unchanged?

[beenish-majeed]

Thanks for checking these views. The comparison makes the discrepancy much clearer.

The repository homepage still lists JrSantiaggo, but Insights → Contributors (All) shows only henri-ralmeida, with all 267 commits. The current main history, underlying author and committer metadata, and co-author checks are consistent with that result.

Based on this evidence, stale or inconsistent contributor data in the homepage sidebar is the most likely explanation. The exact internal cause remains unconfirmed, and the REST contributors endpoint has not been independently verified.

Could a GitHub staff member please investigate whether the homepage Contributors sidebar for henri-ralmeida/prumo can be refreshed on GitHub's side?

There is a relevant precedent: in [another discussion about a stale contributors sidebar](https://github.com/orgs/community/discussions/205858), a GitHub staff member confirmed that they had refreshed the contributor list and recommended contacting GitHub Support if the problem recurred.

GitHub's [contributor documentation](https://docs.github.com/en/repositories/viewing-activity-and-data-for-your-repository/viewing-a-projects-contributors) notes that contributor displays and statistics can take approximately 24 hours to refresh after history changes. Since I don't have a verified timestamp for any previous history rewrite, I won't assume that this waiting period has elapsed.

I'd prefer to resolve this without renaming main, rewriting history, or pushing artificial commits just to trigger a possible refresh. I haven't found a documented, user-accessible mechanism to force a recalculation of the homepage sidebar, and changing repository configuration solely to troubleshoot displayed statistics seems unnecessary when the current history is consistent.

The repository's existing MIT license and original project credit will remain untouched. The goal is simply to make the automatically generated contributor list accurately reflect the repository's current state.

A GitHub-side investigation or refresh would be the most direct, least disruptive next step. It would allow the discrepancy to be addressed without risking the branch configuration, CI, pull requests, integrations, or existing attribution.