The Git team has released version 2.42, with a notable change being that the warning about creating repositories with SHA-256 hashing has been toned down, with a promise of “only compatible changes” in future.

The previous version stated that “SHA-256 support is experimental and still in an early stage … it should be assumed that, e.g., Git internal file formats in relation to SHA-256 repositories may change in backwards-incompatible ways. Only use –object-format=sha256 for testing purposes.”

It seems that developers now have the green light to use SHA-256 repositories in production – though note that no major providers like GitHub, GitLab or Bitbucket support it. While the documentation still warns that “at present, there is no interoperability between SHA-256 repositories and SHA-1 repositories,” it now says that if changes are required in future, “it can be expected that SHA-256 repositories created with today’s Git will be usable by future version of Git without data loss.” That said, SHA-1 remains the default.

The history here is that Git uses a hash function to name files, directories and revisions. This makes it easy to detect corrupted content, and that communication methods “have a short reliable string that can be used to reliably address stored content,” as the transition document explains. However, in 2017 researchers discovered flaws in SHA-1, and although Git moved to a hardened implementation “SHA-1 is still weak. Thus it’s considered prudent past any variant of SHA-1 to a new hash,” the docs continue. The risk is that if SHA-1 were broken, “we could not trust that a given hash value represented the known good version of content that the speaker intended.”

SHA-256 was picked as the successor in late 2018 but until now developers have been discouraged from using it. Lack of interoperability with SHA-1 remains an issue; this is planned via a translation table but is not yet implemented.

When will providers support SHA-256 repositories? A comment from GitLab is telling. “Indeed we’re well aware of SHA1’s shortcomings, and we continue to work towards SHA256 support in our products. However given that actual hash collisions are quite rare (and usually artificial), we’re prioritizing projects that give more immediate benefits to our customers,” said engineering manager Andras Horvath in January. Perhaps though it could be a competitive advantage. “It would be the single feature that would get me to switch from GitHub to GitLab,” said a potential customer.

The full release notes for Git 2.42 show that there is plenty more in this release, including performance improvements, bug fixes, and a new mechanism to keep “unreachable objects”, which would otherwise be pruned.