Re: some (fairly simple) questions about hooks
- From
Ævar Arnfjörð Bjarmason <avarab@gmail.com>
- Date
- May 30, 2018, 11:14 UTC
- Message-ID
- <877enlflaa.fsf@evledraar.gmail.com>
- In-Reply-To
- <alpine.LFD.2.21.1805300700190.7958@localhost.localdomain>
On Wed, May 30 2018, Robert P. J. Day wrote:
Show 5 quoted lines
> just want to clarify a few things about hooks to make sure i'm not > missing anything when i write my own hooks tutorial. > > first, for any hook to be active, it *must* be marked as executable > -- that much seems clear from the man page.
Yes.
Show 8 quoted lines
> next, "core.hooksPath" aside, the hooks related to any repository > are (by default) in $GIT_DIR/hooks and *only* in that directory. AIUI, > there is no way to extend or enhance the per-repo hooks with, perhaps, > a common subset of hooks in a common directory, is there? (i'm > ignoring the possibility that one could populate $GIT_DIR/hooks with a > few symlinks to share some common hooks among a number of repos -- > would that work? and is it something that is even considered good > programming practice?)
Yes. There's git-native no way to have N number of the same type of hooks. core.hooksPath is all or nothing.
See https://public-inbox.org/git/877eqqnq22.fsf@evledraar.gmail.com/ for some musings of mine about potential future plans here & workarounds in place in the wild, e.g. GitLab's support for N number of server-side hooks.
You can also use e.g. the "pee" utility frome moreutils (https://joeyh.name/code/moreutils/) to accomplish the same thing.
> next, AIUI, the use of "core.hooksPath" *completely* overrides any > hooks in $GIT_DIR/hooks, yes? that is, that config setting does not > support any sort of enhancement of existing hooks, it's all or > nothing, correct?
Yes.
> and sticking with core.hooksPath, one could set it either globally > to affect all repos, or one could of course set it locally to take > advantage of it just for *some* repos, but not all of them.
Yes, this is not special to core.hooksPath but (almost) all config variables (aside from stuff like per-remote config which can't be set globally).
> finally, if you run "git init" for an existing repo, as i read it, > based on the templates content in effect, that will install new hooks > in a repo but *only* hooks for which there is no existing equivalent > -- it will *never* overwrite an existing hook by the same name.
Yes "git init" can re-initialize an existing repo, but will not clobber existing stuff (or shouldn't).
Show 5 quoted lines
> oh, and related to that last paragraph, running "git init" related > to hooks should be unaffected by core.hooksPath, is that correct? so > that even if "git init" installs some new hooks in an existing repo, > those new hooks will have no effect if core.hooksPath is set to refer > somewhere else, yes?
Yes "git init" will just inject the hooks into .git/hooks, because it doesn't care about hooks, it's just re-injecting stuff found in the template dir, and the "hooks" dir is just one of the things that happens to exist there.
> am i missing any important features of hooks in the above?
Not that I can think of.