Unreachable commit

[omercengiz]

🏷️ Discussion Type

Question

Title

Question about unreachable commits in private repositories

Body

Hi,

I have a general question about GitHub's handling of unreachable commits in private repositories.

If an unreachable commit contains sensitive data, what is the usual process for having it removed from GitHub?

In particular:

• Is repository-owner approval required?
• Is the repository owner normally notified?
• Does GitHub Support need temporary access to the repository?

Thanks.

Guidelines

• I have read and understood this category's guidelines before making this post.

[c20744531]

Hey, I'm not GitHub staff, so take this as what I understand from the docs. Support can confirm the details.

Treat the data as already leaked. Revoke or change any passwords, tokens, or keys that were in the commit first. That matters more than the removal.
Removal goes through GitHub Support. Unreachable commits can still be viewed by their hash, so you contact Support and ask them to clear cached views and run garbage collection on the repo. The GitHub Docs page "Removing sensitive data from a repository" walks through it.
Owner approval and notification. Since it's the owner's private content, the request normally has to come from the owner or an admin of the repo. I'm not aware of a fixed rule about who gets notified, so ask Support directly.
Support access. I don't know of any case where they browse a private repo without permission. They'd normally ask first. Worth asking them to confirm how it works for your case.

If the commit is still in a branch or pull request, you'll want to clean that history too (git filter-repo is the usual tool) before asking Support to purge it.

[aniketatgithub]

Rewriting history and force pushing is only the first half. Per GitHub's docs on removing sensitive data, the old commits can still be reachable through clones or forks, directly by their SHA in cached views, and through pull requests that reference them.

For the GitHub-hosted copies, the documented path is to contact GitHub Support through the support portal and ask for the cached views and the references in pull requests to be removed. GitHub is explicit that Support will only assist with removal of sensitive data, and the exposed credential should be treated as compromised and rotated, since that is the part that actually closes the hole. Data in other people's clones and forks cannot be removed by GitHub at all.

On your process questions: this removal is not self-serve from the repository UI, it goes through a Support ticket. Whether Support needs any temporary access, or notifies the repository owner, is something they confirm on the ticket; the docs do not promise either, so I would not assume.

[sharanrenukeshbharmshetty]

Hi! GitHub distinguishes between making a commit unreachable and removing sensitive data that may still be accessible through cached views or references.

If an unreachable commit contains sensitive information, the general process is:

1. Revoke or rotate any exposed credentials, such as API keys, passwords, or tokens.
2. Use git-filter-repo to remove the sensitive information from the repository's history. If necessary, force-push the cleaned history and coordinate with collaborators.
3. Contact GitHub Support if sensitive information remains accessible through cached views or references, following GitHub's documented removal process.

Regarding your questions:

• Repository-owner approval: GitHub's documentation does not establish a universal owner-approval requirement for every removal request. The requirements may depend on the circumstances.
• Repository-owner notification: The documented process does not specify a universal notification rule for every unreachable-commit removal request. GitHub Support can clarify this for your specific case.
• Temporary repository access: Temporary access is not described as a standard prerequisite in GitHub's documented sensitive-data removal process.

Simply making a commit unreachable does not guarantee that sensitive data has been removed from GitHub's cached views or other references.

Official documentation:
https://github.com/proxy/docs.github.com/en/authentication/keeping-your-account-and-data-secure/removing-sensitive-data-from-a-repository

I hope this helps!

[AnthonyKebadilwe]

Quick heads up: an unreachable commit isn’t gone just because no branch points to it. Anyone with the full SHA can still open it through cached views, and old pull request references can keep it alive too. So the cleanup has a few parts, and the first one has nothing to do with GitHub.

1. Treat the data as leaked. Rotate the password, revoke the token, regenerate the key. Do this before anything else. Removal takes time, and GitHub can’t touch copies sitting in other people’s clones or forks, so the rotation is what actually closes the hole.

2. Clean the history. If the commit is still reachable from a branch, tag or PR, scrub it with git filter-repo and force push. Then ask collaborators to re-clone, because one stale clone can push the old history right back.

3. Open a ticket with GitHub Support. This isn’t a button in the repo settings. Go to support.github.com, give them the repo name and the full commit SHA, and ask them to clear cached views, drop PR references to it and run garbage collection.

On your three questions:

Owner approval: GitHub’s docs don’t lay down a fixed rule. File the ticket from the owner’s account or an admin account and you avoid any back and forth.
Owner notification: The docs don’t say either. Ask in the ticket so you get an answer for your exact case.
Temporary access: It isn’t listed as a standard step in the removal process. If you want certainty, ask Support to spell out in the ticket whether they need any access to the repo, and on what terms, before you agree to anything.

The official walkthrough is “Removing sensitive data from a repository” in GitHub Docs.