Git 3.0 may accept only lowercase hex object IDs

Git developer brian m. carlson has proposed restricting hexadecimal object IDs to lowercase only in Git 3.0, arguing that accepting uppercase has long fed bugs and security problems across the ecosystem.

Git has always printed object IDs in lowercase, yet its parsers still take uppercase letters. Carlson notes that Git-adjacent software, including Gitolite and Git's own sample hooks, commonly expects only the characters 0-9 and a-f. Tools that make that assumption can mishandle uppercase input, and developers sometimes treat a hex object ID as having a single canonical string form when it does not. In Carlson's view, those false uniqueness assumptions are a security liability for anything that keys policy or trust on the hex spelling.

Maintainer Junio C Hamano said he would queue the series while inviting further comment. His practical side favors taking it and treating fallout as a problem for third-party reimplementations; his principled side is uneasy about abandoning liberal acceptance of input. Carlson replied that Postel's Law fits modern software poorly, pointing to request smuggling and similar failures where lenient parsers let components disagree about the same data.

Jeff King separately showed that uppercase hex inside commit and tag objects can yield otherwise identical parallel histories with different hashes, and those objects do not round-trip cleanly through hash interoperability code. Others demonstrated that mixed-case IDs are accepted today and can leave different consumers seeing different strings for the same object.

The restriction would land under Git's breaking-changes mode ahead of 3.0. Carlson's work found only one existing test that depended on uppercase acceptance, a sign of how little the lenient path is exercised in practice.