Safe-commit-hook: prevent developers from checking in sensitive files | Hacker News Reader

Safe-commit-hook: prevent developers from checking in sensitive files

github.com

42 pointsjenandre8 comments

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.

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.

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.

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.

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

https://github.com/jandre/safe-commit-hook/blob/master/git-d...

> schema.rb

Don't you kind of need this in a rails project?

No, you can make do without it. ActiveRecord will connect to your database and learn about your tables at runtime, and if you want you can choose to think of the combination of all your migrations as the source of truth for your schema.

That said I've seen this done, but wouldn't recommend it. Your schema.rb is helpful to collaborators and running through all of your migrations on a new base is silly.

Why would you simply rely on extensions instead of, say, also the file's magic numbers?

Reply on news.ycombinator.com