27

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?

Alexander Gladysh
  • 39,865
  • 32
  • 103
  • 160

8 Answers8

14

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
  • 208,672
  • 30
  • 90
  • 92
9

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
  • 771
  • 8
  • 4
  • 1
    The github for this looks a little inactive, but there's a more active branch at `https://github.com/git-hooks/git-hooks`. – jelford Aug 24 '14 at 11:32
4

In Git 2.9, you can point to a custom hooks directory using the core.hooksPath configuration.

Git 2.9 Release Notes - https://github.com/blog/2188-git-2-9-has-been-released

Documentation mentioning core.hooksPath - https://git-scm.com/docs/githooks

Note - this question is a possible duplicate of Can Git hook scripts be managed along with the repository?

Community
  • 1
  • 1
Max Shenfield
  • 3,927
  • 2
  • 13
  • 16
3

pre-commit has a bunch of features that look promising

  • Works for many languages, and has a plugin architecture to add support for other languages
  • Capable of bootstrapping the hook dependencies (language dependent)
  • Applies hooks incrementally (only run hooks on changes that are part of the commit)
  • Leverages the init.templateDir so newly checked out repos automatically install the correct hooks
  • Temporarily disable a specific hook using an environment variable - don't skip all the checks just because you can't run one of them

Source code here

CoatedMoose
  • 3,624
  • 1
  • 20
  • 36
2

For NodeJS-based projects, I suggest you taking a look at ghooks.

gtramontina
  • 1,096
  • 9
  • 10
1

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
  • 23,174
  • 7
  • 66
  • 88
0

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
  • 103,207
  • 26
  • 155
  • 191
  • That git commit --no-verify is dangerous. It is hard to rebase when you have bad commits. – Alexander Gladysh Jan 12 '10 at 23:04
  • 1
    @Alexander, git rebase will also take a --no-verify flag. – Wayne Conrad Jan 12 '10 at 23:19
  • Thanks, I've missed it. Still... a hack. :-) – Alexander Gladysh Jan 13 '10 at 08:47
  • 1
    I still don't understand why it's dangerous. – Wayne Conrad Jan 13 '10 at 20:16
  • 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 Jan 14 '10 at 09:10
  • 1
    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 Jan 18 '10 at 03:46
0

Command git config core.hooksPath $CUSTOM_GIT_HOOKS_PATH will set your hooks path to the required folder; you can configure this for multiple gits and use the same hook scripts for all of them

if you want global hooks configuration git config --global core.hooksPath $CUSTOM_GIT_HOOKS_PATH

for managing your GitHooks inside VSCode you can try out my extension GitHooks

GitHooks VSCode Marketplace Link

Lakshmikanth Ayyadevara
  • 101
  • 2
  • 6