For someone to be able to break your repo using sha1 collisions, they need to be able to commit to it.
If you don't trust someone, don't let them commit to your repo.
> Were they so in love with the performance of C/C++ being able to pass around 20 byte hashes on the stack without worrying about a more complicated structure (eg a collection of variable length hashes)?
The hashes show up everywhere. They're how every object in git is identified. They make it onto disk. They're not just commit ids.
They might not need to commit to your repo to break it using SHA-1 collisions.
They might, for example, compute a collision, commit the malicious version to a private GitHub repository, and then send you a patch with the non-malicious version via email, or by sending you a merge request on GitLab. When you accept and merge in their changes and then push to GitHub, perhaps GitHub will recognize the hash of one of your blobs as a hash that it already knows the blob for (from the private commit), and so it will ignore whatever data you send it for that blob.
Maybe that particular scenario won't work — I haven't tried it — but there are hundreds of possible angles of attack. Fundamentally the security of Git is based on the idea that hashes don't collide.
If I'm looking at a PR which contains a hash collision with code that does a `sudo rm -rf --no-preserve-root /` and I don't accept the malicious code, the hash collision becomes irrelevant.
If you don't trust someone, don't let them commit to your repo.
> Were they so in love with the performance of C/C++ being able to pass around 20 byte hashes on the stack without worrying about a more complicated structure (eg a collection of variable length hashes)?
The hashes show up everywhere. They're how every object in git is identified. They make it onto disk. They're not just commit ids.
Changing hashes changes the disk format.