Git would have to first decide whether a file is a textfile or binary file, a decision that can be done reasonably well heuristically but that is undecidable in the general case. Then it has to parse text files for a long, curated list of known keywords that are only used for storing API keys and are not (usually) used in normal code. I'm not sure if that's even feasable.
And then of course git has no concept of "public" and "private" repos, so the entire task can't be handled well by git.
That's all I'm trying to say
We keep expecting a cat to bark, and then we're shocked and disappointed that it doesn't. So let's stop asking and find / build a better tool.
We. Need. A. New. Tool.
p.s. But there are how many CSS pre-processors? And how many JS frameworks? Etc. Things we don't need. Go figure.
It might not catch everything all the time - since humans are pretty creative when it comes to fucking things up - but I bet it would be pretty effective. Certainly more effective than what we have now. Then if it can keep learning going forward, all the better, eh.
In comparison Gmail doesn't catch all cases either, if you say something like "here are" instead of I've attached it misses it.
Passwords, look for variables with the name password, passwd assigned strings.
Like Gmails attachment, it'll get stuff wrong, just make it easy to continue on.
if "PASSWORD=xxx" in text => prompt alert or ask confirm
Next step would be to take this list (search result), make a curated list of 100-1000 unencrypted password (text/line + files + infos of repo), and then hard code some rules to detect +80% of cases.
That is, for example, if Gmail can ask "it looks like you forgot the attachment" why can't Git say "this is a public repo and you're about to commit and push passwords. Are you sure?"
It's going to be easier to fix the tool than it is to make humans be perfect.