Git's Next Decade: Evolution, Not Revolution

In a thought-provoking presentation at FOSDEM 2026, Patrick Steinhardt outlined the critical transitions Git must undergo to remain relevant in its third decade. As the version control system that has achieved near-universal adoption among developers, Git faces mounting pressure to evolve while maintaining the stability that has made it indispensable.

The case for evolution

Steinhardt began by acknowledging Git's remarkable success: millions of repositories, countless scripts depending on it, and dominance in the open-source world. Yet he emphasized that Git was designed for a different era—when SHA-1 was considered secure, Linux was the largest repository, CI pipelines were rare, and the tool's complexity was already a challenge.

"The world has changed quite a bit since Git was first released in 2005," he noted, highlighting three major shifts: cryptographic vulnerabilities in SHA-1, the explosion of monorepos like Chromium that dwarf the Linux kernel, and the ubiquity of CI pipelines that trigger numerous jobs with each commit. Despite these changes, Git cannot afford a revolutionary overhaul. "The unique position of Git means that it can't have a revolution; too many projects and developers rely on it. Instead, it needs to evolve."

SHA-256 migration: A necessary but challenging transition

The most visible change underway is Git's migration from SHA-1 to SHA-256. While Git's use of SHA-1 was never primarily for security—serving mainly as an integrity check and content-addressable naming system—the cryptographic community's successful attacks on SHA-1 have made migration imperative.

Steinhardt explained the complexity: when developers sign commits, they're signing SHA-1 hashes. Binary blobs like firmware can't be easily inspected for malicious changes, and tooling across the ecosystem assumes collision resistance. Government mandates to remove SHA-1 by 2030 add regulatory pressure.

Git added SHA-256 support in version 2.29 (October 2020), but adoption remains minimal due to lack of ecosystem support. "Nobody is using it because it is not supported by large forges, and large forges are not implementing support because there's no demand." This chicken-and-egg problem threatens to leave Git vulnerable as SHA-1 attacks become more feasible.

Git 3.0 will make SHA-256 the default for new repositories, forcing the ecosystem to adapt. Steinhardt acknowledged this transition "will likely not be an easy one, and it may result in a few hiccups along the road." The release timeline remains uncertain, with discussions ongoing about whether to ship in October 2025.

Reftables: Rethinking reference storage

Steinhardt's enthusiasm was palpable when discussing reftables, which he called his "favorite topic." The current loose reference system—storing each reference as a separate file in refs/heads/—scales poorly. With hundreds or thousands of references, filesystem limitations become severe: case-insensitive filesystems prevent branches differing only in case, and each reference consumes 4KB of storage regardless of size.

Packed references help but introduce computational expense. Steinhardt cited a GitLab repository with 20 million references where deleting a reference requires rewriting 2GB of data. Concurrency presents another challenge: simultaneous readers and writers cannot obtain consistent views of all references.

Reftables solve these problems through a binary format that enables atomic updates and eliminates filesystem limitations. Steinhardt emphasized that users should always access references through Git commands rather than direct filesystem manipulation. "If you use Git in scripts or on the server side, you should make sure you don't play weird games by accessing references directly on the filesystem."

Large files and the promise of promisors

For most developers, reference scalability issues are theoretical. The more pressing concern is Git's poor handling of large files. Steinhardt noted that 75% of GitLab's storage is consumed by binary files larger than 1MB, and repository maintenance becomes computationally expensive.

Current workarounds like Git LFS and git-annex are insufficient. Partial clones help users but don't address server-side challenges, and forges cannot offload files to CDNs like other web services. The solution lies in large-object promisors—separate remotes that store only large blobs while the main remote handles other objects.

This functionality, built directly into Git, allows transparent client operation and enables serving large objects via protocols like S3, facilitating CDN offloading. Steinhardt emphasized that promisors are "quite close to being usable on the client side," though forge support remains undetermined.

Pluggable object databases represent the longer-term solution. Steinhardt argued that Git needs a storage format designed specifically for binaries where incremental changes cause minimal storage growth. The format must remain compatible with existing storage to allow mixing text and binary files. While progress has been made in refactoring Git's object access, implementing a viable binary format will take longer.

Learning from Jujutsu: UI improvements

Perhaps the most surprising revelation was Git's willingness to learn from Jujutsu, a Git-compatible version control system written in Rust. Steinhardt admitted his initial dismissal of Jujutsu, but changed his mind after observing its growing popularity.

"That moment when you realize that a tool simply fixes all the UI issues that you had and that you have been developing for the last 20 years was not exactly great," he confessed. Jujutsu's innovations include default history malleability (permanent interactive rebase mode without confusion), automatic rebasing of dependents when history changes, and treating conflicts as data rather than emergencies.

Git cannot completely revamp its UI, but it can adopt specific improvements. Steinhardt announced two new commands planned for Git 2.54: "git history split" and "git history reword," designed to simplify workflows like splitting commits that currently require seven separate commands. Future releases will add more history-editing subcommands inspired by Jujutsu.

Community involvement and the path forward

Steinhardt closed by emphasizing that Git's evolution requires community participation. Users can encourage forges to implement SHA-256 support, test SHA-256 with new projects, and contribute to third-party tool support. The promisors and pluggable object database efforts progress in parallel, with promisors closer to practical use.

The presentation revealed a project acutely aware of its responsibilities and limitations. Git cannot break compatibility or introduce revolutionary changes, but it must address fundamental challenges around security, scalability, and usability. The planned changes—SHA-256 migration, reftables, large-object promisors, pluggable storage, and UI improvements—represent a carefully calibrated evolution that preserves Git's strengths while addressing its growing pains.

As Steinhardt noted, this was a "whirlwind tour" of ongoing work, but it painted a clear picture: Git is preparing for its third decade with the same pragmatic approach that made it successful in the first two. The question remains whether the ecosystem can move quickly enough to address security concerns before the next cryptographic vulnerability emerges.