Re: [PATCH 0/5] Multiple hook support
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Apr 24, 2019, 02:41 UTC
- Message-ID
- <xmqqk1fk2kgq.fsf@gitster-ct.c.googlers.com>
- In-Reply-To
- <20190424022240.GH6316@genre.crustytoothpaste.net>
"brian m. carlson" <sandals@crustytoothpaste.net> writes:
Show 19 quoted lines
> On Wed, Apr 24, 2019 at 11:09:10AM +0900, Junio C Hamano wrote: >> "brian m. carlson" <sandals@crustytoothpaste.net> 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 > approach.
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.