All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Johannes Sixt <j6t@kdbg.org>,
	"brian m. carlson" <sandals@crustytoothpaste.net>,
	git@vger.kernel.org, Jeff King <peff@peff.net>,
	Duy Nguyen <pclouds@gmail.com>,
	Johannes Schindelin <Johannes.Schindelin@gmx.de>
Subject: Re: [PATCH 1/5] run-command: add preliminary support for multiple hooks
Date: Thu, 25 Apr 2019 11:39:38 +0200	[thread overview]
Message-ID: <87lfzys9t1.fsf@evledraar.gmail.com> (raw)
In-Reply-To: <xmqqo94uzyxa.fsf@gitster-ct.c.googlers.com>


On Thu, Apr 25 2019, Junio C Hamano wrote:

> Johannes Sixt <j6t@kdbg.org> writes:
>
>> Furthermore, basing a decision on whether a file is executable won't
>> work on Windows as intended. So, it is better to aim for an existence check.
>
> That is a good point.
>
> So it may be OK for "do we have a single hook script for this hook
> name?" to say "no" when the path exists but not executable on
> POSIXPERM systems, but it is better to say "yes" for consistency
> across platforms (I think that is one of the reasons why we use
> .sample suffix these days).
>
> And for the same reason, for the purpose of deciding "because we do
> not have a single hook script, let's peek into .d directory
> ourselves", mere presence of the file with that name, regardless of
> the executable bit, should signal that we should not handle the .d
> directory.
>
> IOW, you think access(X_OK) should be more like access(F_OK)?

To me this is another point in favor of bypassing this problem entirely
and adopting the semantics GitLab (and it seems others) use. I.e. in
order execute:

    .git/hooks/pre-receive .git/hooks/pre-receive.d/*

Instead of going further down this avenue of:

    if exists_or_executable_or_whatever .git/hooks/pre-receive
    then
        .git/hooks/pre-receive
    else
        for hook in .git/hooks/pre-receive.d/*
        do
            $hook
        done
    fi

It also:

 1) Makes it easier for users to experiment with more granular hooks if
    they have one big pre-receive hook by adding pre-receive.d/* hooks
    without having to move their existing pre-receive to
    pre-receive.d/000-existing hook (which will be incompatible across
    git versions!).

 2) Is compatible with any existing trampoline scripts you might want to
    migrate from that *don't* use pre-receive.d/*, e.g. one script in
    our infrastructure (that I didn't write) does:

        my ($hook_phase, $dir) = fileparse($0);
        my $exit = 0;
        my @hooks = glob("${dir}${hook_phase}-*");
        for my $hook (@hooks) {
            next unless -x $hook;
            $exit |= system $hook;
        }
        exit ($exit >> 8);

   I.e. you have a ".git/hooks/pre-receive" trampoline and it runs
   ".git/hooks/pre-receive-*" scripts.

It occurs to me that we might want to make things configurable for the
#2 case. I.e. have a core.hooksDSuffix=".d/" by default, but you could
also set it to "-". So we'd then construct a glob of either
"pre-receive.d/*" or "pre-receive-*" from that.

  reply	other threads:[~2019-04-25  9:39 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-24  0:49 [PATCH 0/5] Multiple hook support brian m. carlson
2019-04-24  0:49 ` [PATCH 1/5] run-command: add preliminary support for multiple hooks brian m. carlson
2019-04-24  2:27   ` Junio C Hamano
2019-04-24 18:48     ` Johannes Sixt
2019-04-25  0:55       ` Junio C Hamano
2019-04-25  9:39         ` Ævar Arnfjörð Bjarmason [this message]
2019-04-25 10:04           ` Junio C Hamano
2019-04-25 19:40         ` Johannes Sixt
2019-04-26 20:58           ` brian m. carlson
2019-04-26 21:53             ` Johannes Sixt
2019-04-24 22:32     ` brian m. carlson
2019-04-24  0:49 ` [PATCH 2/5] builtin/receive-pack: add " brian m. carlson
2019-04-24  0:49 ` [PATCH 3/5] sequencer: " brian m. carlson
2019-04-24  9:51   ` Phillip Wood
2019-04-24 22:46     ` brian m. carlson
2019-04-25 14:59       ` Phillip Wood
2019-04-24  0:49 ` [PATCH 4/5] builtin/worktree: add support for multiple post-checkout hooks brian m. carlson
2019-04-24  0:49 ` [PATCH 5/5] transport: add support for multiple pre-push hooks brian m. carlson
2019-04-24  2:09 ` [PATCH 0/5] Multiple hook support Junio C Hamano
2019-04-24  2:22   ` brian m. carlson
2019-04-24  2:41     ` Junio C Hamano
2019-04-24  8:14     ` Ævar Arnfjörð Bjarmason
2019-04-24  2:34 ` Jonathan Nieder
2019-04-24  7:43   ` Ævar Arnfjörð Bjarmason
2019-04-24  8:22   ` Ævar Arnfjörð Bjarmason
2019-04-24 23:07   ` brian m. carlson
2019-04-24 23:26     ` Jonathan Nieder
2019-04-25 10:08     ` How to undo previously set configuration? (again) Ævar Arnfjörð Bjarmason
2019-04-25 10:43       ` Duy Nguyen
2019-04-25 11:58         ` Ævar Arnfjörð Bjarmason
2019-04-26 15:18           ` Ævar Arnfjörð Bjarmason
2019-04-25 14:36       ` Jonathan Nieder
2019-04-25 14:43         ` Barret Rhoden
2019-04-25 15:27           ` Ævar Arnfjörð Bjarmason
2019-04-25 15:25         ` Ævar Arnfjörð Bjarmason
2019-04-26  2:13         ` Junio C Hamano
2019-04-26  9:36         ` Duy Nguyen
2019-04-30 21:14           ` Jeff King
2019-05-01 11:41             ` Duy Nguyen
2019-05-01 12:18               ` Ævar Arnfjörð Bjarmason
2019-05-01 12:32                 ` Duy Nguyen
2019-05-01 21:09                   ` Jeff King
2019-05-01 21:15                 ` Jeff King
2019-04-24  8:10 ` [PATCH 0/5] Multiple hook support Ævar Arnfjörð Bjarmason
2019-04-24  9:55   ` Phillip Wood
2019-04-24 18:29   ` Bryan Turner
2019-04-24  9:49 ` Duy Nguyen
2019-04-24 22:49   ` brian m. carlson
2019-04-24 23:40   ` brian m. carlson
2019-04-25  0:08     ` Duy Nguyen
2019-04-30 21:39 ` Jeff King

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=87lfzys9t1.fsf@evledraar.gmail.com \
    --to=avarab@gmail.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=j6t@kdbg.org \
    --cc=pclouds@gmail.com \
    --cc=peff@peff.net \
    --cc=sandals@crustytoothpaste.net \
    /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.