Re: [PATCH 0/5] Multiple hook support

[Bryan Turner <bturner@atlassian.com>]

On Wed, Apr 24, 2019 at 1:10 AM Ævar Arnfjörð Bjarmason
<avarab@gmail.com> wrote:
>
> On Wed, Apr 24 2019, brian m. carlson wrote:
>
> > Oftentimes, people want to use multiple of the same kind of hook. This
> > may be because software or a project they use requires a given hook, but
> > they would also like to have a custom hook, or because they're using
> > multiple pieces of software that both require involvement with the same
> > hook.
> >
> > This series introduces support for multiple hooks by using a ".d"
> > directory. For example, instead of using a single
> > ".git/hooks/post-checkout" file, you'd use multiple files within
> > ".git/hooks/post-checkout.d". This is the standard Unix paradigm for
> > multiple files and should be familiar to most people. Hooks are executed
> > in sorted order.
>
> I think it's interesting if people can chime in with current in-the-wild
> implementations of this.
>

Bitbucket Server also uses trampoline scripts for pre-receive and
post-receive that loop over scripts in matching *.d directories and
run them.

* It passes --template to "git init" (new repositories) and "git
clone" (forks) to have Git copy hook structure into place as part of
creating the repository.
* To avoid looping over thousands or tens of thousands of repositories
if those scripts need to change, the scripts put in place (both at the
pre-receive/post-receive level and for *.d/20_bitbucket_callback) are
essentially placeholders that use environment variables exported when
running "git http-backend" and "git receive-pack" to delegate to
helper scripts that actually do the work.
* The helper scripts only exist in one place, so they can easily be
updated if they need to change.
* When looping over *.d scripts, the helper script stops after the
first non-zero return.

On Tue, Apr 23, 2019 at 7:41 PM Junio C Hamano <gitster@pobox.com> wrote:
>
> One downside is that the transition from the old to the new world
> order becomes a bigger deal.  You could have been using a precursor
> of this series implemented entirely as a shell script
>
>         $ cat >.git/pre-commit <<\EOF
>         #!/bin/sh
>         for x in .git/pre-commit.d/*
>         do
>                 "$x" "$@" || exit 1
>         done
>         exit 0
>         EOF
>         $ chmod +x .git/pre-commit
>
> and with your approach, the user can keep using that set-up and then
> simply remove that single file once all the Git executables the user
> uses are natively aware of the multi-hook setup.  With "either a
> file or directory" approach, the transition would be removing the
> file *and* renaming pre-commit.d directory to pre-commit.
>

This would be true for Bitbucket Server, since its trampoline scripts
are really simple: It could just delete them and let Git loop over the
existing *.d directories itself, so the current approach offers a
really straightforward upgrade path.

Of course, since Bitbucket Server supports a range of Git versions on
the server, and for compatibility reasons the minimum is only raised
in major version releases, it would likely be quite some time before
that could happen; the minimum supported Git version would need this
series to have landed in or before it. That's a big part of why
Bitbucket Server doesn't use core.hooksPath; it's too new. (Bitbucket
Server 6.0 raised the minimum Git version on the server to 2.11.0, so
it's the first major series that could use core.hooksPath; Bitbucket
Server 5.x supported back to Git 2.2.0, which doesn't have it.)

Best regards,
Bryan Turner