On Wed, Apr 24, 2019 at 1:10 AM Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> 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@xxxxxxxxx> 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
