From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: "Robert P. J. Day" <rpjday@crashcourse.ca>
Cc: Git Mailing list <git@vger.kernel.org>
Subject: Re: some (fairly simple) questions about hooks
Date: Wed, 30 May 2018 13:14:05 +0200 [thread overview]
Message-ID: <877enlflaa.fsf@evledraar.gmail.com> (raw)
In-Reply-To: <alpine.LFD.2.21.1805300700190.7958@localhost.localdomain>
On Wed, May 30 2018, Robert P. J. Day wrote:
> 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.
> 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).
> 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.
prev parent reply other threads:[~2018-05-30 11:14 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-30 11:00 some (fairly simple) questions about hooks Robert P. J. Day
2018-05-30 11:14 ` Ævar Arnfjörð Bjarmason [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=877enlflaa.fsf@evledraar.gmail.com \
--to=avarab@gmail.com \
--cc=git@vger.kernel.org \
--cc=rpjday@crashcourse.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.