Does Git have plan to change their hash function?

Question

Let's say in the future SHA1 is cracked to the point where it's possible to create malicious commits for a given commit ID. Do the Git folks have a contingency migration plan to change their hash function without requiring clients and repositories to upgrade simultaneously?

Does the current version of Git have any code to intelligently recognize different hash algorithms and provide a good message to the user if it doesn't recognize it? Is the hash algorithm stored anywhere in the repo? Will they add prefixes to the hashes like $#$ in /etc/shadow to indicate a different hash algorithm?

Answer 1

This comes up pretty frequently.

A recent thread shows that as recently as November 2014, this is a somewhat involved change:

Is there a plan for upgrading to a better hash function in the future? (E.g., should it become an urgent need.)

What are the roadblocks to adoption of a replacement hash function? Just documenting this would go a long way towards making it possible to upgrade some day.

The biggest obstacle is the assumption of SHA-1 everywhere in the source code (e.g. assume the object name always takes 20 bytes). Brian started on cleaning that up [1] but I think it's stalled. Then we need to deal with upgrade path for SHA-1 repos.

If and when the Git developers decide to move away from SHA-1 they will have some work to do. There doesn't appear to be a clear plan at the moment, but it seems that there are no major technical roadblocks.