My goal is to check commit data that don’t meet certain requirements and then reject either the commit being created or pushed to the remote repository.
The problem of doing a pre-commit hook is that it’s hard to deploy to many people who have to manually update their pre-commit hook file. As well, Git does not allow you to have submodules in the .git folder which would’ve been very easy for deployment yet alas.
The other option I see is doing the checking in I believe the update hook on the remote side, which will check each commit being pushed by a dev and reject the push if any of the commits fail the tests.
Does anyone have any insight on this problem? And if so, could you provide or point me towards an example update hook script? I’m a little confused as to how it works.
1
you must first figure out whether you don’t want the unqualified code to be committed or to be pushed/published back to upstream.
in my opinion the later one is more feasible.
with a DVCS like git. you don’t really want to control how every developer uses his local repository. and you can’t really have control over that.
a pre-commit hook works well as basic validation and sanitization, if everyone involved embrace it voluntarily. we actually enforce that loosely in our company. however, it can always be skipped with git commit --no-verify.
server side hook, on the other hand, doesn’t intervene a programmer’s local workflow, and makes sure that others in the project base their work only on code that meets certain criteria. normally this is what people look for when they implement automatic checks.
this automatic validation isn’t meant to replace quality control, i guess, which is usually achieved with code review or pair programming.
if you are familiar with github, you’d notice that “pull request” is yet another approach to this issue. many open source projects and companies use github’s pull request for branch permission control and code review. but it needs human interaction, thus may not be what you’re asking for.
As you already pointed out, doing this on the client, while technically possible, is probably not practical. Also, many git users commit interim work, so having draconian checks on every commit is counterproductive.
The standard solution would be a server-side hook. You’d probably set up a pre-receive hook, which runs every time a push comes in, and which can reject the push if it wants to. The rest depends on the exact checks you want to make.
This is explained in Pro Git, chapter 7.3 Customizing Git – Git Hooks.
1