Re: [PATCH 0/5] Multiple hook support

From: Junio C Hamano <gitster@pobox.com>
To: "brian m. carlson" <sandals@crustytoothpaste.net>
Cc: git@vger.kernel.org, Jeff King <peff@peff.net>,
	Duy Nguyen <pclouds@gmail.com>,
	Johannes Schindelin <Johannes.Schindelin@gmx.de>
Subject: Re: [PATCH 0/5] Multiple hook support
Date: Wed, 24 Apr 2019 11:41:41 +0900	[thread overview]
Message-ID: <xmqqk1fk2kgq.fsf@gitster-ct.c.googlers.com> (raw)
In-Reply-To: <20190424022240.GH6316@genre.crustytoothpaste.net> (brian m. carlson's message of "Wed, 24 Apr 2019 02:22:41 +0000")

"brian m. carlson" <sandals@crustytoothpaste.net> writes:

> 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.