Scott Chacon sent a four-patch RFC after saying he is worried about the ecosystem impact of making SHA-256 the git init default in Git 3.0. The series teaches git tag -s --hash=sha256 and git commit -S --hash=sha256 to compute a SHA-256 digest over every file in the tree, including submodules, and put it into the signed object. This works in a repository that still uses SHA-1 object names.

Chacon later said the thread contains two separate questions: the merits of an independent content hash in a signed header, which he finds interesting but not fundamental, and whether the 3.0 default object format should be SHA-256 or SHA-1. He called the SHA-1 weakness his approach addresses a very niche problem.

Brian m. carlson called that an oversimplification. He argued that people do not realize Git uses SHA-1, and that once SHA-256 is the default they will welcome it. He said the need to leave SHA-1 will become urgent for a large segment of major institutions, and that he has had inquiries from large government agencies and corporations who know about SHA-256 and want it. He also said the open source community has asked for it.

Patrick Steinhardt said the ecosystem did nothing about SHA-256 until the project announced the move would become mandatory, and that only then could developers get time, and employer backing, to implement support. He said things are finally moving as the deadline approaches, and that he would be very hesitant to change course now, because the ecosystem would likely stop working on it again.

Chacon replied with a different account of the history. He pushed back on the idea that the transition was something everyone wanted and that GitHub was merely pulled into by the 3.0 decision. He said GitHub has been essentially the only organization pushing the effort from the start.

No one has reviewed the patches themselves in the excerpts, and the 3.0 default question remains open in the thread.