If I were putting government procedure on a blockchain, I'd want something stronger than SHA1 for the edges.
What? Why?
Because it's outdated and not fit for use in adversarial contexts: https://security.googleblog.com/2017/02/announcing-first-sha...
Most git repos are not adversarial, so they get away with using it. A malicious commit which put a loop or a fork in your commit history would just be rejected--if not by the software, then by the maintainer.
But if you're tracking the state of some legal procedure in congress or whatever, you really don't want anybody playing games with history, since presumably it would determine important societal outcomes like whether a bill became law.
I thought the explanation was that SHA1 collision attacks on git repositories weren’t feasible, not that we don’t care about people sneaking things into our git repositories.
I did a bit of research (landed here: https://marc.info/?l=git&m=115678778717621&w=2). It's not that
> we don’t care about people sneaking things into our git repositories
But rather that in the event of a collision, git would not sneak the attacker's malicious code into your repo. The best such an attacker can expect to achieve is to create confusion. In a project-maintainer scenario, that probably just means rejecting the PR--hardly an outcome that would justify spending the money on the hash collision in the first place.
In a we're-voting-on-whether-or-not-to-change-the-law scenario, confusion about the outcome of the vote could have dire enough consequences that an adversary might indeed care enough to bother with the calculation.
That's not to say that this is the only way in which git would be a bad choice, it's just the first that came to mind.