A new hash algorithm for Git

Perhaps the translation table should be signed. After the repository is converted to SHA-256, someone trusted (e.g. Linus Torvalds) can run a tool that scans through the translation table, fetches the object corresponding to each SHA-256, computes its SHA-1, verifies the translation table says the same SHA-1, then signs the translation.

Then a regular user can verify a commit (identified by its SHA-256) by using the signed translation table to find the corresponding SHA-1 and checking the committer's signature of that SHA-1. That avoids the performance cost of having to fetch the entire object from disk to compute its SHA-1 before checking the signature, while avoiding the danger of a falsified translation table that tries to link the signed SHA-1 to a totally different commit that doesn't actually match that SHA-1.

As a bonus, if SHA-1 gets completely broken in the future, I think the repository would remain secure. If a future attacker can manufacture a commit whose SHA-1 matches an old signed commit, they could try to insert that commit into the repository with a valid translation table entry (containing the colliding SHA-1 and a new non-colliding SHA-256) and reuse the old commit's signature on their new commit (since it's only signing the SHA-1). If the translation table was unsigned, the attacker could succeed. But if it was signed, there's no way to insert the new translation table entry without tricking Linus into signing the new table. And Linus can avoid being tricked if he simply stops signing any new translation tables beyond the point when SHA-1 gets completely broken (which should be many years away).