I actually see what the kernel.org folks are doing as one of the best examples of dealing with a compromise that I've seen.
as for your objection that they are running commands on the system to track the extent of the problem, that is something that they pretty much must do, having a spare system with those sort of specs laying around just in case it's needed isn't practical (the thing holds 66 drives for crying out loud, that's _expensive_ and there is a good case to be made for keeping all of that expensive hardware that's been donated in use rather than just sitting around.
they have said that as far as they can tell the git repository has not been tampered with (and they say how they know that), so if you downloaded via git and compiled, you should be good.
it's not just assuming that the filesystem hasn't been changed, it's also the fact that all of the people who pull through the git interface (that you are saying may send trojened source) are automatically doing checks on the data.
yes it's theoretically possible to backdoor git so that it sends valid data to some people and invalid data to other people, but since the git transport layer isn't encrypted, it would be far easier to do this via a man-in-the-middle attack on your network than it would be to compromise kernel.org to do this for you.