Git RFC floats signed SHA-256 tree digests as SHA-1 exit ramp

Scott Chacon has floated an RFC that would let Git embed a verifiable SHA-256 digest of a commit or tag's full tree contents inside the signed object, without forcing the repository itself onto the SHA-256 object format. The idea is offered as a lighter alternative to the planned Git 3.0 change that would make SHA-256 the default for newly initialized repositories, a shift Chacon argues could fracture the ecosystem before tooling and forges are ready.

Under the proposal, signing a commit or tag with an explicit hash option (or a config default) would walk the tree, hash every blob's content plus submodule trees by path, and place the resulting SHA-256 value in a new header that older Git versions simply ignore. Verification would continue to work as today. Chacon presents it as a way to gain stronger content assurances for signed releases while leaving the bulk of existing SHA-1 repositories and workflows undisturbed.

Brian M. Carlson rejected the approach as insufficient. Git needs collision resistance at the object-store level, he argued, because colliding blobs cannot coexist; once SHA-1 weakens further, repositories that must store arbitrary data (security research among them) will require native SHA-256. Government timelines already press users to abandon SHA-1, major forges already expose SHA-256 support, and the 3.0 default has been discussed for years. A half-measure that only strengthens signatures does not solve the storage problem and arrives too late to rewrite the long-standing transition plan.

Patrick Steinhardt added that the ecosystem largely ignored SHA-256 work until a hard deadline appeared; reversing course now would simply stall progress again and make future breaking changes harder. Chacon countered that practical access remains limited (GitHub's offering is still effectively closed, other forges experimental), that key compatibility pieces are unfinished, and that the default change risks bifurcating users for a problem most never encounter. Junio C. Hamano offered implementation notes but withheld judgment on the larger direction.

Side discussion turned to the still-incomplete interoperability layer that would rewrite objects on fetch or clone, submodule migration pain, and the real cost of moving large histories. The exchange leaves the 3.0 default on the table while underscoring how much migration machinery and forge readiness still sit between today's SHA-1 world and a clean cutover.