Git hooks management

tags:

git
githooks

views:

403

answers:

+8 Q:

Git hooks management

We use custom-written Git hooks in our project.

Hooks are stored in a project's repository, and, when they do change, to get a new version each user must copy them manually in his .git/hooks directory. This is rather inconvenient.

One way to improve this is to make .git/hooks a symlink into worktree. But this would imply that each branch (even user's local feature branches under development) should have the most current version of hooks. This is not convenient as well.

How would you solve the problem?

+3 A:

Maintain a separate repository of your hooks and symlink into that.

I agree, it'd be nice if Git had a built-in mechanism for propagating hooks scripts but it doesn't.

Pat Notz 2010-01-12 16:35:02

That is an option, of course, but this is one more repository to update in the morning... For each developer. Guess I need some more automation...

Alexander Gladysh 2010-01-12 23:02:29

We made .git/hooks a symlink into the working tree.

For those rare occasions when someone needs to commit files that the hooks will reject, we use git commit --no-verify

Wayne Conrad 2010-01-12 17:41:12

That git commit --no-verify is dangerous. It is hard to rebase when you have bad commits.

Alexander Gladysh 2010-01-12 23:04:53

@Alexander, git rebase will also take a --no-verify flag.

Wayne Conrad 2010-01-12 23:19:33

Thanks, I've missed it. Still... a hack. :-)

Alexander Gladysh 2010-01-13 08:47:50

I still don't understand why it's dangerous.

Wayne Conrad 2010-01-13 20:16:00

No, no longer dangerous (at least in a sense I meant in a first comment) — git rebase --no-verify should save the day.But a hack — if you have installed the hooks, why to bypass them? This means that either hooks are imperfect, or your code is wrong.I agree, of course, that in practice there would be cases where --no-verify is unavoidable.

Alexander Gladysh 2010-01-14 09:10:25

Actually, it means that the hooks are correct for the shared repository, and we want those checks early even when we're working on a branch locally. But sometimes, we temporarily want to check code into a local branch that fails the hooks (usually a "work in progress" commit when the tree is full of debug code, which the hooks reject). The branch will be made to pass the hooks and rebased to remove the "in progress" commits before pushing it upstream. You say hack, I say sometimes you need to take the guard off of the machine and put a stick in one of the gears.

Wayne Conrad 2010-01-18 03:46:35

+3 A:

http://benjamin-meyer.blogspot.com/2010/06/managing-project-user-and-global-git.html appears to be a convenient way to automate hook symlinking, to facilitate global, per user, and per project hooks.

kergoth 2010-09-02 18:54:34

+1 A:

You could make the repository's .git directory a git repository, and just add hooks and other config to it, adding the objects, refs, etc. directories and files like index to its .gitignore. Not only that, but you could set up a post-receive hook to update the metarepo from its origin. Once you had the initial configuration set up, you could have it pull in updates without any additional effort.

I'm working out the details of this, like what should go in the ignore list; I'm keeping the results in branches of this repo.

intuited 2010-10-10 01:36:20

ansaurus

tags:

views:

answers:

Git hooks management

related questions