SHA-256 Git Object Format Support on GitHub

[Mpolo-hub]

🏷️ Discussion Type

Question

💬 Feature/Topic Area

Other

Body

Hello GitHub Community,

I am preparing the architecture of a new software project called MOKILI. Before creating its first repository and making the first commit, I need to clarify GitHub's support for Git's native SHA-256 object format.

Git supports initializing a repository with:

git init --object-format=sha256

Could anyone from GitHub confirm whether GitHub currently supports hosting and maintaining repositories using this native SHA-256 object format?

In particular:

1. Can a new GitHub repository use SHA-256 as its native object format?
2. Are clone, fetch, push and pull fully supported without conversion to SHA-1?
3. Are Pull Requests, merge commits and branch protection supported?
4. Is GitHub Actions compatible with SHA-256 repositories?
5. Do GitHub APIs correctly support 64-character SHA-256 object identifiers?
6. Are signed commits and SSH signature verification supported?
7. Are forks, tags, releases and downloadable source archives supported?
8. Are there any known limitations or compatibility restrictions?
9. Is SHA-256 repository support officially production-ready?

If SHA-256 repositories are not supported, is there an official roadmap for this functionality?

This is an important architectural decision for MOKILI because our security model relies on Git commit history and independently verifiable cryptographic evidence.

I understand that community members may not be able to provide an official commitment. If a GitHub employee or maintainer could point me to official documentation or the appropriate support channel, I would greatly appreciate it.

Thank you!

[Zabeeh-Ullah-Dev]

Short answer: no, GitHub does not support SHA-256 repositories yet. Git on your own machine can create one with git init --object-format=sha256, but GitHub only hosts SHA-1 repositories. If you try to push a SHA-256 repo to GitHub, the push will fail.

That answers most of your list in one go. Since the repo itself cannot live on GitHub in that format, there is no SHA-256 clone, push, pull, pull request, fork, Actions run, or 64-character object ID support on GitHub.

For MOKILI, I would start with a normal SHA-1 repo on GitHub and use signed commits (GPG or SSH signing) for commit authenticity. That is the supported way to get verifiable commits today.

As far as I know, GitHub has not announced a public roadmap or date for SHA-256 repo support. If you need an official answer for a compliance decision, GitHub Support is the right place to ask, since only they can confirm plans.

[100rootrain]

The earlier reply is right: GitHub can't host SHA-256 repositories today. Since this decision is hard to undo, here's how to verify that yourself, and what it means for the design.

You can check what GitHub accepts

Every Git server announces which object formats it speaks. GitHub announces only SHA-1:

$ GIT_TRACE_PACKET=1 git ls-remote https://github.com/git/git HEAD 2>&1 | grep object-format
git< object-format=sha1

If you push a SHA-256 repository, Git stops before it sends anything, with the receiving end does not support this repository's hash algorithm (send-pack.c). So for questions 1–7 and 9 the answer is the same: there's no SHA-256 repository on GitHub, so there are no PRs, Actions, forks, archives or 64-character IDs for one. The API only ever returns 40-character SHA-1 IDs.

Roadmap: the public github/roadmap has no SHA-256 item. The existing feature request, #154056 (March 2025, 80+ upvotes), has no staff reply. Upvote it, and use GitHub Support if you need a written answer for compliance.

Why you have to decide before the first commit

• The format is fixed when the repository is created. Git can't convert a repository in place. GitLab's docs state it plainly: "Git does not support migrating to SHA-256 later, or migrating back to SHA-1."

• Converting later means rewriting history. You can replay history into a new SHA-256 repository, but every commit ID changes, and existing commit and tag signatures don't carry over, because each one signs an object that contains the old IDs. If your security model relies on stable, signed history, a later switch is a break in that chain.

• There's no bridge either. Git doesn't yet interoperate between SHA-1 and SHA-256 repositories (Git 2.42 release notes). A SHA-256 primary with a GitHub mirror isn't possible without that kind of conversion.

• Watch out for Git 3.0. It will make SHA-256 the default for new repositories. No release date has been set, and the stated prerequisite is that forges are ready (BreakingChanges). If you host on GitHub, set the format explicitly so a future git init doesn't create a repo GitHub rejects. git clone always copies the remote's format, so it isn't affected.

  git config --global init.defaultObjectFormat sha1

The two realistic options for MOKILI

If SHA-256 is a hard requirement, GitHub is out for now:

• Forgejo (and so Codeberg) supports SHA-256 repositories.
• GitLab offers it as an Experiment behind a feature flag. Its docs say it's "not ready for production use."

Test the full workflow you need (CI, signing, archives) on whichever you pick. The ecosystem around SHA-256 is still thin.

If GitHub is a hard requirement, use SHA-1 and add evidence that doesn't depend on it:

• SHA-1 here isn't plain SHA-1. Git and GitHub use a collision-detecting SHA-1 that rejects objects built with the known collision attacks (GitHub blog).
• Sign commits and tags. GitHub verifies both GPG and SSH signatures. Turn on vigilant mode, and require signed commits in a ruleset.
• Anchor releases with SHA-256. GitHub records an immutable SHA-256 digest for every uploaded release asset, in the UI and in the API's digest field. Artifact attestations (actions/attest-build-provenance) add signed provenance keyed by SHA-256. Publish your own git archive tarball as an asset, and don't rely on the auto-generated source archives.

That gives you independently verifiable SHA-256 evidence for what you ship, even though commit IDs stay SHA-1.

[Mpolo-hub]

Thank you very much fir your answer. I will do it.

…

On Fri, Nov 13, 2026, 7:00 AM 백근우 ***@***.***> wrote: The earlier reply is right: GitHub can't host SHA-256 repositories today. Since this decision is hard to undo, here's how to verify that yourself, and what it means for the design. You can check what GitHub accepts Every Git server announces which object formats it speaks. GitHub announces only SHA-1: $ GIT_TRACE_PACKET=1 git ls-remote https://github.com/git/git HEAD 2>&1 | grep object-formatgit< object-format=sha1 If you push a SHA-256 repository, Git stops before it sends anything, with the receiving end does not support this repository's hash algorithm ( send-pack.c <https://github.com/git/git/blob/master/send-pack.c>). So for questions 1–7 and 9 the answer is the same: there's no SHA-256 repository on GitHub, so there are no PRs, Actions, forks, archives or 64-character IDs for one. The API only ever returns 40-character SHA-1 IDs. *Roadmap:* the public github/roadmap <https://github.com/github/roadmap> has no SHA-256 item. The existing feature request, #154056 <#154056> (March 2025, 80+ upvotes), has no staff reply. Upvote it, and use GitHub Support <https://support.github.com/contact> if you need a written answer for compliance. Why you have to decide before the first commit - *The format is fixed when the repository is created.* Git can't convert a repository in place. GitLab's docs state it plainly: "Git does not support migrating to SHA-256 later, or migrating back to SHA-1." - *Converting later means rewriting history.* You can replay history into a new SHA-256 repository, but every commit ID changes, and existing commit and tag signatures don't carry over, because each one signs an object that contains the old IDs. If your security model relies on stable, signed history, a later switch is a break in that chain. - *There's no bridge either.* Git doesn't yet interoperate between SHA-1 and SHA-256 repositories (Git 2.42 release notes <https://github.com/git/git/blob/master/Documentation/RelNotes/2.42.0.adoc>). A SHA-256 primary with a GitHub mirror isn't possible without that kind of conversion. - *Watch out for Git 3.0.* It will make SHA-256 the default for *new* repositories. No release date has been set, and the stated prerequisite is that forges are ready (BreakingChanges <https://git-scm.com/docs/BreakingChanges>). If you host on GitHub, set the format explicitly so a future git init doesn't create a repo GitHub rejects. git clone always copies the remote's format, so it isn't affected. git config --global init.defaultObjectFormat sha1 The two realistic options for MOKILI *If SHA-256 is a hard requirement,* GitHub is out for now: - *Forgejo (and so Codeberg)* supports SHA-256 repositories. - *GitLab* offers it as an *Experiment* behind a feature flag. Its docs <https://docs.gitlab.com/user/project/#create-a-project-that-uses-sha-256-hashing> say it's "not ready for production use." Test the full workflow you need (CI, signing, archives) on whichever you pick. The ecosystem around SHA-256 is still thin. *If GitHub is a hard requirement,* use SHA-1 and add evidence that doesn't depend on it: - *SHA-1 here isn't plain SHA-1.* Git and GitHub use a collision-detecting SHA-1 that rejects objects built with the known collision attacks (GitHub blog <https://github.blog/news-insights/company-news/sha-1-collision-detection-on-github-com/> ). - *Sign commits and tags.* GitHub verifies both GPG and SSH signatures. Turn on vigilant mode, and require signed commits in a ruleset. - *Anchor releases with SHA-256.* GitHub records an immutable SHA-256 digest for every uploaded release asset, in the UI and in the API's digest field. Artifact attestations (actions/attest-build-provenance) add signed provenance keyed by SHA-256. Publish your own git archive tarball as an asset, and don't rely on the auto-generated source archives. That gives you independently verifiable SHA-256 evidence for what you ship, even though commit IDs stay SHA-1. — Reply to this email directly, view it on GitHub <#212994?email_source=notifications&email_token=BMIFGKEUXEHISPMRGNHZJOT5Y2PPNA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOJVHAZTINZSUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVRTG633UMVZF6Y3MNFRWW#discussioncomment-19583472>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BMIFGKHZFTM65WIOWYDYN4D5Y2PPNAVCNFSNUABIKJSXA33TNF2G64TZHMZTAMJVG4ZTGNBUHNCGS43DOVZXG2LPNY5TCMJSHE4DAOJYUF3AE> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/BMIFGKHQQ7H22FVJ23GBPM35Y2PPNA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOJVHAZTINZSUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVJTG633UMVZF62LPOM> and Android <https://github.com/notifications/mobile/android/BMIFGKHCGF7IMG6RVSJFOZT5Y2PPNA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOJVHAZTINZSUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVZTG633UMVZF6YLOMRZG62LE>. Download it today! You are receiving this because you authored the thread.Message ID: ***@***.***>

[kaluarachchiteshan]

Hi,

I'm not a GitHub staff member, but here is what I know.

Current status

As far as I can find, GitHub has not announced support for SHA-256 repositories, and I'm not aware of an official roadmap or documentation page for it. A third-party article dated October 2026 says the same. Treat it as unsupported unless GitHub says otherwise.

Reports from other users point the same way:

• Pushing a SHA-256 repository has failed with errors such as fatal: protocol error: unexpected capabilities^{}.
• Importing a SHA-256 repository from another host has failed.

I haven't reproduced these myself.

What this means for your questions

Since a SHA-256 repository can't be hosted on GitHub today, most of your list (pull requests, branch protection, Actions, the APIs with 64-character IDs, signature verification, forks, releases, archives) can't be answered as "supported". I wouldn't assume any of them work. If you need an authoritative answer on a specific item, GitHub Support is the only reliable source.

Git itself

• SHA-256 has existed in Git since 2.29 as experimental. Newer Git versions treat it as stable.
• A SHA-1 repository and a SHA-256 repository can't push to or fetch from each other.
• Git has no in-place conversion. You'd replay the history into a new SHA-256 repository.

Options for MOKILI

1. Use a host that supports SHA-256. Forgejo/Codeberg and self-hosted Git over SSH or HTTP work for SHA-256, but check each one's current limits (web UI, CI and API support differ).
2. Use SHA-1 on GitHub, and add your own integrity evidence. If you need independently verifiable history:
   • sign commits and tags (SSH or GPG)
   • publish signed release manifests with SHA-256 checksums of the archives or artifacts
   • keep a mirror or bundle (git bundle create) with its hash recorded elsewhere
     Git's hardened SHA-1 (default since 2.13) blocks the known practical collision attack, but it is not a long-term guarantee, and signatures cover the commit content, not the hash function itself.
3. Run both. Keep the canonical SHA-256 repository on a host that supports it, and publish a read-only SHA-1 mirror on GitHub for visibility. Note that mirroring across formats means converting history, so commit IDs differ between the two.

To get an official answer

• Ask GitHub Support: https://support.github.com/contact
• Check the GitHub Changelog (https://github.blog/changelog/) and the public roadmap (GitHub Public Roadmap) for any announcement.
• Before committing to a design, run git init --object-format=sha256 locally, create a test repository on GitHub, and try a push. That is the quickest way to see current behavior for your account.