It seems to me like the time horizon for an attack on git based on SHA-1 collisions would be much, much longer than other similar collision attacks (like signin

It seems to me like the time horizon for an attack on git based on SHA-1 collisions would be much, much longer than other similar collision attacks (like signing binary executables), because of the sequential nature of version control. Presumably the utility of such an attack would be to maliciously insert code into an earlier version of the code to hide its origins, in which case for each commit on the file, they'd need to calculate a collision that contains their changes plus whatever legitimate changes have been made to that file. I'm not familiar enough with the inner workings of git to know, but I imagine it would be a pain to juggle updating new commits from people working from a local copy of the repo - potentially your malfeasance would be detected quickly if you tried to calculate a diff between the old file and the new file from the local copy (which would presumably not be updated, given that the checksums match). That said, if people are in the habit of signing their tags/commits using SHA-1, then that would be just as vulnerable as any other signing problem.