So what's stopping them from running git blame?

Interviewer time is expensive and candidate time is cheap.

Running git blame is faster than waiting 30 minutes for the results of a whiteboard test.

Running, then cleaning and then having a dataset that still needs interpretation.

I'd take the 30 minute interview route and risk not hiring a clever programmer.

Aren't we trying to hire clever programmers? Isn't that the point?

If a guy has some kind of a git-mutating program that makes it seem like he writes good stuff, he's probably a good programmer to be able to write such a thing.

...or knows how to download such a thing and run it.

Such a thing doesn't exist, but besides, why not spend 30 minutes asking about what challenges they dealt with at their job instead?

If they can't talk about what problems they solved, they probably didn't solve any.

I guess everything I do is 'solving problems'. That's pretty open-ended. Maybe 'describe a situation where things didn't work the way they were supposed to/documented to work. How did you resolve it?' or something like that.

That's what I meant by problems, things like when everything went wrong and you had to fix it.