Granted, signed tags do depend on this collision resistance, but I don’t use that feature. Signing entire releases from a trusted repo seems like a better approach.
Sure, if you use git with a very closed development model, this doesn't necessarily affect you much. But it's (potentially) a big problem for collaborative open-source projects, because it requires trust in every single contributor. And the trust requirement can't necessarily be mitigated using ordinary means like code reviews.
Besides, the known collision attack generates files with blocks of binary garbage, which makes it difficult to trick someone into accepting. It won't look like source code, and if someone accepts binary blobs of executable code, you don't need collisions to pwn them.
IDK, I could see this happening in multiple ways.
1. Images / media artifacts stored for display purposes
2. Cached files - 'zero install' config for yarn comes to mind, where every dependency has its file cached in git.
Plus binary files aren't displayed in git diffs so it seems somewhat easy to sneak in.
Otherwise, yeah, agree. Most people don't rely on Git's security model, they rely on Github's.
They are (albeit not as prominently as they should). And you can add your own diff engines to show full diffs for different binary formats.
Upstream Git client says "Binary files a/filename and b/filename differ" whenever it detects changes a binary file. This is mentioned in output of 'git diff', 'git status', 'git show' and other commands.