No too much load, really. We (Bitbucket) already have pre-receive hooks for a handful of other things. The trick would be defining the rules properly to have a reasonably low false negative rate while avoiding work inhibiting false positives (or allow for a mechanism to override it with, say, a force push).

Of course, 93% of our repositories are private so this feature may not be exceedingly useful to our customers vs other things we could be spending our time on.

Edit: I shouldn't have said not useful, rather, comparatively there may be more value in us pursuing other work first. E.g., provide a mechanism for 3rd party pre-receive hooks via our add-on system.

It is still useful. Even if the repository is private, it can be shared with people who shouldn't have that private key.

Interesting to see that percentage of repos is private.

Is BitBucket separate from Atlassian? Are you hiring? ;)

We're very focused on professional teams working on private projects -- but you can't see that because they're all private. Bitbucket is sort of like an iceberg: 1. you can only see a small percentage of the of the total mass; 2. it is blue.

Yes, we're part of Atlassian and we're hiring in San Francisco.

Can't afford to move to SFO unfortunately - any plans to expand remote work?

FWIW Github already scans your commits for Github OAuth tokens and revokes any tokens it found. Doesn't prevent you from checking in SSH keys or anything like that but it's something, right? (Source: I did this once with a non-priviledged token. Oops.)

Yeah, definitely hard to do for free probably, but it's a potentially great value add, and could be an additional service an organization/user could pay for.