Removed co-author commits 5+ days ago, extra contributor still shown on profile and repo card

[swagmachine999]

🏷️ Discussion Type

Question

Body

Hello,

My repository swagmachine999/tunnelka_proxy had commits with a co-author trailer that
I did not want to credit. I rewrote the history with git filter-branch and force-pushed
all branches and tags more than 5 days ago, and did it once more today. The default
branch and all tags now have only one author, and the contributors API lists only my
account.

However, an extra contributor is still shown in two places: the "Built by" icons next
to the repository on my profile activity, and the repository card. This is more than
the 24 hours that the docs mention for contributor data to refresh.

What I checked:

• git log on every branch and tag shows a single author and no Co-authored-by lines
• the contributors API returns only my account
• the repository has 29 old pull request refs (refs/pull/*) that may still hold the
  previous commits

Questions:

1. Does refs/pull/* keep old commits attached to the contributor data?
2. Is there a way to refresh the contributor cache or remove the stale entry
   without deleting and recreating the repository?

Thank you.

[Bubblegunn]

Very likely, yes. GitHub marks refs/pull/* as read-only, so a filter-branch plus force-push cannot rewrite them, and every commit a pull request ever pointed at stays reachable. I hit the same thing after rewriting a repository's main branch to remove a co-author trailer: the default branch was clean, but the old commit was still reachable from the pull request page.

GitHub's guide "Removing sensitive data from a repository" covers this step. After the rewrite, you contact GitHub Support through the support portal with the repository, the number of affected pull requests and the first changed commit(s). Support can dereference or delete the affected pull requests and remove cached views. The guide does not say how the contributor icons are computed, so I cannot promise they clear the moment the refs go. But the old pull request refs are the only place those commits still live, so that is the ticket to open. You should not need to delete and recreate the repository.

To check the branch itself from your side: I maintain surviving-lines (https://github.com/Bubblegunn/surviving-lines), a small CLI that lists who wrote the lines still alive at HEAD next to each author's commit share. It reads git blame and git log, so it can confirm what the branch now attributes. It cannot see refs/pull or GitHub's cache.

[NexzaDev]

Bubblegunn's point about refs/pull/* is the most likely cause. A few additions that may help narrow it down:

Why the old commits can still be reachable

• Pull request refs are read-only on GitHub's side, so git filter-branch plus a force-push can't rewrite them. Any commit referenced by one of those 29 refs stays in the repository.
• Even after a ref is gone, GitHub can still serve a commit by its SHA until the object is garbage collected, and that only happens on GitHub's side.
• If the repository has ever been forked, the fork network shares objects, so the old commits can persist there as well.

You can check this quickly. Take an old commit SHA from before the rewrite (from your local reflog, for example) and open https://github.com/<owner>/<repo>/commit/<sha>. If it still loads, the old history is still reachable and the stale attribution has a source.

On your two questions

1. Yes, those refs can keep the old commits attached to the repository's data, so they are a plausible reason the extra contributor is still showing.
2. I don't know of any user-facing way to refresh or clear the contributor cache, and I haven't found documentation on how the "Built by" icons are calculated. I'd avoid deleting and recreating the repository until Support has looked at it. As Bubblegunn said, that shouldn't be necessary.

What to send to GitHub Support

Contact them through support.github.com using the "Removing sensitive data" route and include:

• The repository name
• The number of affected pull requests (29)
• The first changed commit SHA, and an example of an old SHA that still resolves
• A note that the issue is the stale contributor icon on the profile and repo card, so they know to refresh that too

Be aware that if the pull requests are removed or dereferenced, you may lose their diffs and discussion, so it's worth saving anything you want to keep first.

Even once the refs are cleared, the icons might take some time to update, so I'd ask Support to confirm whether a cache refresh is needed on their end.

[swagmachine999]

Thank you both, this is very helpful.

I checked it: the old commit SHA still opens on GitHub, and refs/pull/* still
holds the previous commits (29 pull requests), so that is the source.

I did try GitHub Support, but my ticket was closed by the virtual assistant because
my account has only self-service support options, so that route is not available
to me. Is there any other way to get the old pull request refs cleared, or is
recreating the repository the only option for a free account?

Thanks again. @Bubblegunn @NexzaDev

[Bubblegunn]

Free accounts can still reach GitHub Support for account, security and abuse issues. That is what the "About GitHub Support" page lists, and credential or data exposure falls under security. So it may be worth one more ticket, opened directly at support.github.com with the security / sensitive-data topic rather than through the assistant chat. One limit, though: the sensitive-data guide says Support does not remove non-sensitive data. If the co-author trailer carried a personal email address, say so, because that makes it personal data. If it was only a name, they may decline.

If that fails, recreating the repository is the only route I know of on a free account. Deleting a repository removes its refs/pull/* with it. Before you do it:

• export the issues and pull request discussions you want to keep (gh issue list --json …, gh pr view --json …);
• note that stars, watchers and issue numbers do not carry over;
• check for forks first, because a fork keeps the old objects, as NexzaDev said.

Push the cleaned history to the new repository, and check an old SHA URL afterwards to confirm it no longer resolves.

[Bubblegunn]

Before recreating the repository, one cheap thing to try: renaming the default branch away and back made GitHub re-index the contributor list for others (#210296, #197389). Old SHAs will still resolve through refs/pull, but the icons may update. If they do, you can keep the repository.