5 ms·
Safe-commit-hook: prevent developers from checking in sensitive files
- deanclatworthy 11y agoStill 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 11y agogit 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 11y agoYes, 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 11y agoI 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 11y agoYou just add it to the repo itself. Really not a lot of work. You're a dev... automate it.
- caio1982 11y agoWhy would you simply rely on extensions instead of, say, also the file's magic numbers?
- emmab 11y agohttps://github.com/jandre/safe-commit-hook/blob/master/git-deny-patterns.json#L222 https://github.com/jandre/safe-commit-hook/blob/master/git-d... > schema.rb Don't you kind of need this in a rails project?
- zachrose 11y agoNo, 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.