Git isn't relying on collision-resistance, it's relying on second-preimage[0] resistance, which is to say: in order to sneak a hash collision in to a git repository, you have to sneak _something else_ that's already trusted (e.g. via code review) into the repository; collisions can't (yet) be generated for arbitrary hashes.
I haven't heard of any second-preimage attacks against MD5, much less SHA-1, so mlindner was correct in asserting that MD5 would be fine (assuming 128 bits are enough). See also the analysis in [1].
More to the point, if you're able to sneak something into a repository in the first place (e.g. a benign file that generates a collision with a malicious file), then you're probably able to sneak in something more directly (e.g. [2]) that won't rely on both getting something in a trusted repository and then cloning from a different, untrusted source.
[0]: https://en.wikipedia.org/wiki/Preimage_attack
[1]: this is getting a bit old, but should still be relevant? https://electriccoin.co/blog/lessons-from-the-history-of-att...
[2]: https://en.wikipedia.org/wiki/IDN_homograph_attack
I haven't heard of any second-preimage attacks against MD5, much less SHA-1, so mlindner was correct in asserting that MD5 would be fine (assuming 128 bits are enough). See also the analysis in [1].
More to the point, if you're able to sneak something into a repository in the first place (e.g. a benign file that generates a collision with a malicious file), then you're probably able to sneak in something more directly (e.g. [2]) that won't rely on both getting something in a trusted repository and then cloning from a different, untrusted source.
[0]: https://en.wikipedia.org/wiki/Preimage_attack
[1]: this is getting a bit old, but should still be relevant? https://electriccoin.co/blog/lessons-from-the-history-of-att...
[2]: https://en.wikipedia.org/wiki/IDN_homograph_attack