Scott Chacon's RFC proposes signing a SHA-256 digest of the tree in commits and tags, as an alternative to changing the git init default hash in 3.0. The thread this week has largely become about the state of the SHA-256 transition itself.
Christian Couder asked brian m. carlson whether his interoperability work is public. carlson said it is at github.com/bk2204/git.git on the branch sha256-interop, with limitations described in an earlier list message and in Documentation/gitformat-hash.adoc on the branch. He said there is no in-place migration tooling, which is needed for submodules because they must be migrated before the main repository. There are two cases: adding the other hash as an extra mapping, or rewriting all objects to the other hash with the old hash kept as a mapping, as git refs migrate does. He has begun some Rust pieces for this.
carlson also said that fast-export and fast-import can already rewrite submodules, though it is fussy because submodules must be rewritten first. He shared a script to convert git.git. He added that his time is not corporate-funded, partly because he cannot send patches from his work address, as the employer's Outlook corrupts them. Junio C Hamano asked whether a period when only SHA-256 interoperability work was accepted would have worked better, noting it would need buy-in from other stakeholders.
Kristoffer Haugsbakk said git itself does not seem ready. When he tried to migrate the Git repository, the hash-function-transition document did not distinguish implementation from aspiration, and he ended up using git fast-export --all. Johannes Schindelin agreed there has been great reluctance to move to SHA-256. He said that half a year ago he estimated that producing two .c files with the same blob ID, one carrying a malicious payload, would cost about $10k and a month of rented RTX 3090s.