git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
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.

      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

  List information: http://vger.kernel.org/majordomo-info.html

* 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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).