He wrote a summary on Google+
, I'll just quote the intro, skip over to G+ for the whole thing:
I thought I'd write an update on git and SHA1, since the SHA1 collision attack was so prominently in the news.
Quick overview first, with more in-depth explanation below:
(1) First off - the sky isn't falling. There's a big difference between using a cryptographic hash for things like security signing, and using one for generating a "content identifier" for a content-addressable system like git.
(2) Secondly, the nature of this particular SHA1 attack means that it's actually pretty easy to mitigate against, and there's already been two sets of patches posted for that mitigation.
(3) And finally, there's actually a reasonably straightforward transition to some other hash that won't break the world - or even old git repositories.
Anyway, that's the high-level overview, you can stop there unless you are interested in some more details (keyword: "some". If you want more, you should participate in the git mailing list discussions - I'm posting this for the casual git users that might just want to see some random comments).
In one of the comments, Linus also explains why objects with a colliding SHA1 hash won't be an immediate problem for git, while they can be used to destroy, for example, an SVN repository:
SVN (unlike git) just does the SHA1 on the raw object data as the de-dupe mechanism, which is why just feeding the colliding pdf files into SVN triggered the problem.
Git ends up doing the SHA1 not on the raw user data, but on a "git object data", which includes a header with a type and a length. That means that if you just use the poisoned pdf's, git won't actually see the same SHA1 at all for them, and so we don't actually have a "real" git test case for the SHA1 collision yet.