Git's First Breaking Release Since 2014
Read the Portuguese translation →
Author: Better Stack · Watch on YouTube
Video authored by the channel shown, not by IANIA; all rights belong to the creator. Transcript and summary generated automatically; the original-language content is preserved.
Original language: English
Original video: Git’s First Breaking Release Since 2014 · Channel: Better Stack · 01:33 · Watch on YouTube
Topics: Cybersecurity and software security, Software engineering with AI, Open source and software ecosystems
Summary
Section titled “Summary”Git 3 is described as Git’s first breaking release since 2014: it will require Rust, which cannot run on every platform Git supports. The update also proposes moving from SHA-1 to SHA-256 hashes, lengthening commit hashes from 40 to 64 characters and requiring changes to some scripts and CI configurations. Critics say hashes have not provided real security and warn the migration will be disruptive, while supporters point to the growing risk of SHA-1 collisions. Existing repositories will not change for now, there is no official release date, and SHA-256 hashes can already be tried with a Git command.
Key points
Section titled “Key points”- Git 3 will require Rust, which has been enabled by default since June and will no longer be optional.
- The move to Rust is intended to improve memory safety, as many Git security issues have involved memory bugs.
- Rust does not run on every platform that Git supports, so the last version before Git 3 will receive long-term support.
- The proposed hash change replaces SHA-1 with SHA-256, increasing commit hash length from 40 to 64 characters.
- Scripts and CI configurations that expect 40-character hashes will need to be updated.
- A SHA-256 repository will not be able to use a SHA-1 repository as a submodule.
- Scott, GitHub co-founder, called the transition a “global nightmare” and argued that hashes never kept users safe.
- Google’s Git engineers are reportedly not ready to switch and will set SHA-1 as the default in their configuration.
- Existing repositories will not change for now, and Git 3 has no official release date.
- Users can already try SHA-256 hashes with a Git command.
Chapters
Section titled “Chapters”| Start | Chapter | Summary |
|---|---|---|
| 00:00 | Git 3 and the Rust requirement | Git 3 will require Rust for memory safety, though platform compatibility concerns mean the previous version will receive long-term support. |
| 00:30 | The proposed switch to SHA-256 | The video explains the move from SHA-1 to longer SHA-256 commit hashes and the compatibility work this would require. |
| 01:03 | Criticism, risks, and what users can do now | Critics question the security value and readiness of the change, while the video notes that existing repositories remain unchanged and SHA-256 can already be tested. |
Quotes
Section titled “Quotes”Git 3 won’t build without Rust — 00:00
your commit hashes will go from 40 characters to 64. — 00:30
Scott, who co-founded GitHub, called this a global nightmare. — 00:30
your existing repos don’t change — 01:03
Concepts and entities
Section titled “Concepts and entities”Git 3, Git, Rust, SHA-1, SHA-256, Scott, Linus, GitHub, Google
Full transcript (original language)
Section titled “Full transcript (original language)”00:00 Git 3 won’t build without Rust, and that’s not even the most controversial part in this update. This is actually Git’s first breaking release since 2014, and although Rust has been on by default since June, with Git 3, you won’t be able to turn it off. The reason the team made this change was for memory safety. A large number of Git security issues have been memory bugs, but the trouble is Rust doesn’t run on every platform that Git does, so they made the last version before 3 get long-term support. But the bigger, more controversial change in this update is with hashes. Linus picked SHA-1 back in 2005, but
00:30 nowadays people can actually break this by getting two different files to share the same SHA-1 hash. So now they want to switch to SHA-256, so your commit hashes will go from 40 characters to 64. The reason people are upset by this is because every script rejects or CI hash that expects 40 characters is going to need to be updated, and any SHA-256 repo won’t be able to use a SHA-1 repo as a submodule. Scott, who co-founded GitHub, called this a global nightmare. His argument was that the hashes actually never kept you safe. Even Linus said in 2005 real security is in distribution.
01:03 Scott argues that bribing a tired maintainer for access to a repo is probably easier than a SHA-1 exploit. Even Google’s own Git engineers says that they’re not ready, they’ll just switch the default back to SHA-1 in their config. But he does also warn that collisions will only get easier in the future, so when SHA-1 does really break, the whole industry is going to be left scrambling, and they’re going to have to make some unwanted changes. The good news for now though is that your existing repos don’t change, and there’s no official release date for Git 3 yet, but you can actually try SHA-256 hashes now with a simple Git command. Let me know what you think about this in the
01:33 comments, and subscribe to stay up-to-date with developer news.