[deanclatworthy]

Still requires manual effort. We have 100s of repositories at work, and if we were lucky enough to have 100s of developers - they'd all have to do this manually every time.

I've often wondered whether it would be worthwhile for git to include some global configuration to allow global pre/post commit hooks which are opt-out on a per repository basis. If I could do this for every repository our developers created automatically - I would.

[JoshTriplett]

git upstream has rejected that for security reasons; git clone should not produce a repository that runs arbitrary code on the user's system.

However, it seems reasonable to have an explicit option to clone, such as --use-hooks, that allows repositories to enable their local hooks automatically.

Apart from that, you could have a server-side hook that prevents any push containing such files.

[semi-extrinsic]

Yes, a server-side hook is basically an arbitrary python/bash/whatever script with access to the commits being pushed. You can enforce anything server-side.

[gizmo686]

I think the proposal was that a user can create global hooks on their user account. So if you put a hook in ~/.git/hooks, it will act as if it was in $PROJECT_DIR/.git/hooks, unless that specific repository has disabled global hooks.

If you do this, then developers only need to install the hooks once when they set up their machine, and then will already have them when they clone a repo.

[mephux]

You just add it to the repo itself. Really not a lot of work. You're a dev... automate it.