I'm glad you've at least looked into this, but you have a number of things wrong:

  First of all, it is not a single algorithm, it is a family of algorithms

This argument holds for SHA1, but all modern cryptographic hash functions are also families. The SHA3 family has SHA3-224, SHA3-256, SHA3-384, SHA3-512, SHAKE128, and SHAKE256

  For a CRC of size N, you have to also choose a N-bit
  polynomial, N-bit starting value, and N-bit output XOR
  value. There is no single standard, there are tens or
  hundreds of popular options

Apparently you've never heard of CRC32C!

http://www.evanjones.ca/crc32c.html

  Most programming languages have some CRC32 implementation
  - but do not document what parameters they use, or use
  different notation for the same parameters (forward and   
  reverse), or do not let you change the parameters, or do   
  not let you change the CRC size, or all of these. There is 
  no easy way to get a "standard CRC64 or CRC128" compatible 
  across platforms without putting it together from github  
  snippets and example code yourself.

Here's CRC32C implementations in a handful of popular languages:

- C: https://software.intel.com/en-us/node/503522

- Java: http://download.java.net/java/jdk9/docs/api/java/util/zip/CR...

- JavaScript: https://www.npmjs.com/package/fast-crc32c https://www.npmjs.com/package/crc32c

- Go: https://github.com/jacobsa/gcloud/blob/master/gcs/gcsutil/cr...

- Python: https://github.com/ludios/pycrc32c

- Ruby: http://www.rubydoc.info/gems/digest-crc/0.4.1/Digest/CRC32c

And again, I'm not actually recommending git switch to CRC (as a fan of security, I would prefer they use an actual collision resistant hash function). But CRC better meets Linus's stated requirements:

  - CRC will be faster (much faster as in ~4X, your numbers seem off to me) in almost all cases
  - CRC will *not* fail to detect a bitflip, whereas there's a certain probability a random oracle-based construction will