Re: [PATCH 0/5] Multiple hook support
- Date: Wed, 24 Apr 2019 10:14:58 +0200
- From: Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx>
- Subject: Re: [PATCH 0/5] Multiple hook support
On Wed, Apr 24 2019, brian m. carlson wrote:
> On Wed, Apr 24, 2019 at 11:09:10AM +0900, Junio C Hamano wrote:
>> "brian m. carlson" <sandals@xxxxxxxxxxxxxxxxxxxx> writes:
>> > To preserve backwards compatibility, we don't run the hooks in the ".d"
>> > directory if the single file is a valid hook (i.e. it exists and is
>> > executable). This is because some people already have multiple hook
>> > scripts configured, and if we ran them both, we'd run the hooks twice.
>> > This would be bad for e.g. the prepare-commit-msg hook. This is also the
>> > least surprising behavior.
>> OK. An obvious alternative may be to see if the expected hooks path
>> is a directory and use the contents. If ".git/hooks/pre-commit" is
>> a single file, we know it is the single hook as before, and if it is
>> a directory, we know that is not a custom made (i.e. from the world
>> before this series supported in the core-git) multi-hook setup.
> That's an idea I hadn't considered. I'm interested to hear other folks'
> ideas on it, but that certainly avoids a lot of the problems in my
Two things on that:
1. As noted upthread we have some in-the-wild users who use the *.d
semantics already. Would be nice to be able to migrate them, also
*.d is a commonly-used pattern in other software.
2. It's more of a pain in some configuration management systems like
e.g. puppet to change a managed file to a directory than removing an
existing file and adding a directory.