It's not quite that simple. When cryptographic functions are broken, practical vulnerabilities are usually years away. A reduced SHA-1 collision time is certainly a good reason to move away from SHA-1, but it doesn't mean that an attacker can compromise an existing piece of code secured by a SHA-1 hash.

In this case, it is not merely sufficient to find a collision, but to find a collision that is also a valid Git commit, implements a vulnerability, and, ideally, is not immediately obvious at first glance it is a hack (i.e. having kilobytes of garbage data in the commit diff). This is much harder than just finding a random set of bytes that just happens to match the commit SHA-1.

Now, it could be that an organisation like the NSA is sufficiently ahead of public crypto technology that it is capable of not only finding a SHA-1 collision in feasible time, but is also able to craft a malicious Git commit with an identical SHA-1 to a legitimate commit. Inserting such a commit into the Linux source in an appropriate place might result in compromised kernels appearing in commercial products.

But... I kinda doubt anyone is that far ahead, and in any case, it seems extremely risky to try to play such a high-value advantage in a public repository. If someone happens to spot your faked commit, suddenly everyone knows what you are capable of.

So whilst Git would be more secure using SHA-512 or an equivalent, it's currently very unlikely that anyone has the practical capability and will to compromise the kernel's commit log.