Looking forward to Git 2.56 – and 3.0

Original Article ↗ Hacker News Discussion ↗

Plans for Git 2.56 and an eventual 3.0 are prompting debate over how to migrate from SHA‑1 to SHA‑256 without breaking history, tooling, or signatures, and how to verify integrity during that transition. Commenters also weigh the benefits and trade-offs of introducing Rust for safer internals, adopting new storage mechanisms like reftable and pluggable backends instead of filesystem-based refs, and improving long-standing usability issues such as conflict styles, defaults, and support for change IDs. Broader security questions surface as well, including how hash choices interact with quantum threats and whether incremental changes meaningfully improve safety in a large C codebase.

SHA-256 migration and history rewrite

  • Multiple comments debate whether moving from SHA-1 to SHA-256 requires force-pushes and history rewrites.
  • Concerns: history tampering risk during forced pushes; invalidation of SHA-based references in issues, comments, and code; breakage for shallow clones; invalidation of existing commit signatures.
  • Some note that content blobs don’t change, so one can rehash and compare SHA-1 vs SHA-256 histories, but that doesn’t prevent history corruption.
  • Others highlight that Git will not freely mix SHA-1 and SHA-256 repos (e.g., submodules), implying long-lived dual-repo setups and mapping tables.
  • Documentation suggests the change is more like a repack with compatibility layers and lookup tables, not solely a hard cut-over.

Rust adoption in Git

  • One side argues Rust is being “forced” unnecessarily and that a tiny Rust portion doesn’t meaningfully improve security.
  • Others reply that:
    • Incremental improvements matter, especially for new code and parsers, where C has a long history of memory-safety CVEs.
    • Using safer languages for new components is rational, even if legacy C remains.
  • There is discussion of alternative “safe C” approaches (e.g., Fil-C), noting trade-offs in performance and memory.

Storage backends, refs, and reftable

  • Some want Git to “ditch slow files” for a “proper database.”
  • Counterpoint: the filesystem is already a non-relational database; performance issues stem from newer use cases (many refs, hub-style workflows).
  • Work is underway on pluggable backends (reftable for refs; alternative object stores like SQLite, S3, etc.).
  • Reftable is praised for solving ref-name/path issues and case-sensitivity problems, but compatibility with tooling (e.g., libgit2, shell integrations) is a concern.

Defaults, UX, and workflow features

  • Requests for Git 3.0 to fix “bad defaults,” including:
    • Safer push defaults (--force-with-lease, auto remote setup).
    • Better conflict style (zdiff3), improved submodule diffs and recursion, and rerere enabled.
  • Some advocate standardized “change IDs” for commits (as used by Gerrit, jj, GitButler) to support per-commit review, stacked changes, and stable IDs across rebases; current Git commands often drop such headers.
  • Various views on “simple snapshotting”: use git stash, dedicated WIP branches/tags, or external snapshotting tools.

Security and quantum concerns

  • Discussion clarifies that:
    • Length-extension attacks are not relevant to Git’s use of hashes.
    • Quantum threats mainly affect asymmetric crypto; symmetric ciphers and hashes see at most a square-root security reduction.
  • SHA-256 is considered adequate; switching to SHA-3 now is seen as impractical given the long-running transition work already done.

Miscellaneous

  • Notes on GitHub and Bitbucket lagging on SHA-256 support, though GitHub reportedly has private previews.
  • Interest in reftable becoming default, plus side debates on integer commit IDs (as in Mercurial) and filesystem crash behaviors affecting refs.