> OK, so I think "a bit tougher" is an understatement to say the least.
Sure. But the point is that a detecting corruption is a far different beast than detecting intentional collision attempts.
> If they're really worried, compare file sizes too.
This adds nearly no security.
> Then compile the code and verify that the checksum on the executable is the same as before.
Compare the whole binary! If you don't trust a SHA1 on the source, trusting a SHA1 on the binary is merely moving the goalposts around. This also requires deterministic builds - this isn't the default or necessairly easy, but it's possible and is the approach the TOR project takes at least: https://blog.torproject.org/category/tags/deterministic-buil...
Alternatively, even without deterministic builds, compare the whole source tree! The whole file must be read to compute the hash in the first place, so why not compare all those bytes?
> I just think it would be really hard to pull this off
And while I would agree with you on that point, the point I'm trying to make is simply that this has absolutely nothing to do with the fact that git attempts to detect accidental corruption -- the specifics are paramount! While SHA1 is not the weakest cryptographic hash, it is not the strongest cryptographic hash either. Git was not designed to focus on cryptographic security, and it was written by a programmer who is not a cryptographic security expert.
I would also stress that "really hard" is quite different from "impossible" (an in the general case, quite different from even "unlikely".)
(That said, sneaking in a benign-looking backdoor through standard channels sounds way easier.)