It's an obvious critique of git to wonder why SHA1 was chosen over a seemingly free alternative that offers more guarantees.

Git uses SHA1 because it doesen't need a universally secure hash for it to work. What git is after is a "unique id" based on the content and within the key space. SHA1's shorter length is preferable because the guarantee isn't required for the design, and because occasionally it needs to be copied around by hand and compared visually.

After handling git for a while, you will notice the convention used to identify hashes within a project is a truncated hash. This is because the full hash can be implied by only a fraction of its content, this because of the very limited scope of the hash. The hash only refers to the state of a particular source code repository, and the repo has a practical key space requirement of only around 100 to 10,000,000 waypoints, not even close to 2^32. Therefore a collision of git identifiers is acceptable across different contexts.

The secure aspect of git is done with pgp git revision signing which is a completely different toolset. Here uniqueness must be guaranteed universally and something more secure like sha256 can be stored in the signing data where key size doesen't effect usability.