Should SHA-1 be phased out of git, too? I understand that it's more of an issue for certs, but it's still a bit of an issue for anything that uses SHA-1. I'm just asking, not advocating, because the answer will depend on both benefits and costs, and I don't know enough about either in the case of git.
In addition to what others said, I'm really skeptical as to whether it is possible at all to upgrade to something else. The hash is the object ID for all objects stored in Git, most prominently for commits which are referenced by their commit ID (i.e., the SHA-1 hash) all over the place, from internal datastructures to Github URLs.
Rewriting to e.g. SHA-3 would therefore break a lot of references all over the place. Some can be rewritten automatically, some can't (e.g. commit IDs manually entered into commit messages).
Regardless of whether or not it was intended for security, it is used for security now, via signed git commits and git tags. Lots of projects rely on them, and there aren't good alternatives yet; using third-party services like GitHub without signed git commits is very foolish.
Fortunately it's only becoming possible for attackers to create pairs of messages that have the same SHA1 hash; an attacker still can't create a collision between a message of their choosing and an arbitrary SHA1 hash, and that type of attack is probably a long way off. But that's not much safety margin!
A scheme to generate (and sign) a SHA512 hash that more directly incorporates the full state of the repo was invented, and is used by some projects incl. nodejs
Still, I would hope that this is a planned-for possibility, that git might switch hash functions some day. Though it would create repositories that older versions of git can't use, and I don't know if they ever have made a backwards-compatibility breaking change like that.
