From reading various discussions, it sounds like there are quite a few places that make implicit assumptions about the length of the hash, so from a technical p

From reading various discussions, it sounds like there are quite a few places that make implicit assumptions about the length of the hash, so from a technical perspective it might be a hassle to migrate to longer hashes. I think the bigger problem would be external -- tooling and other integrations. I'm guessing if they did move to another algorithm, as part of the migration git would need to re-compute the hash for every single object in all of our repos and migrate all our refs over to the new hashes, so that repos created before and after the change would be indistinguishable. This would mean that every commit hash which appears in plaintext in commit logs, emails, bug trackers, etc. would be wrong. Not to mention 3rd party tools which make the same assumptions about hashes that git itself does. It sounds like a nightmare to me, and one that I would only want to force on the community if absolutely necessary.