Re: [PATCH v2 0/7] Multiple hook support

From: Jonathan Nieder <jrnieder@gmail.com>
Date: May 16, 2019, 00:51 UTC
Message-ID: <20190516005144.GC34155@google.com>
In-Reply-To: <20190516004233.GO7458@genre.crustytoothpaste.net>

brian m. carlson wrote:

> Also, this is the way that most other programs on Unix do this behavior,
> and I think that is a compelling argument for this design in and of
> itself. I think Unix has generally made the best decisions in operating
> system design, and I aim to emulate it as much as possible.

Do a lot of other programs run commands from a specially named subdirectory of the current directory?

If you were talking about a hooks dir in /etc, I would completely agree. But we are talking about .git/hooks/, which has been a constant source of real compromises.

Anyway, I think we've gone back and forth enough times to discover we're not going to agree on this.

[...]

>> This hasn't been a problem for remote helpers, merge drivers, etc in
>> the past.  Why are hooks different?

[...]

Show 6 quoted lines

> Git LFS, for example, installs hooks that warn the user if the command
> isn't installed, since it's a common misconfiguration and not pushing
> the LFS objects (via the pre-push hook) along with the Git objects is a
> common source of data loss. Uninstalling the tool (or not installing it
> if it's a shared repository) doesn't mean the hook still shouldn't be
> run.

I don't understand this example. If the repository is configured to use the Git LFS hooks, why wouldn't it print a friendly message?

[...]

Show 10 quoted lines

> I'm not opposed to extending the config system to implement multiple
> hooks directories or add support for inheriting hooks, because that's a
> common thing that people want. I just don't think our config system is
> the right tool for specifying what commands to run, for the reasons I've
> specified.
>
> I can't prevent you from writing a series that implements a config-based
> option, and if it's the solution the list wants, I'll go along with it,
> but it's not the solution I want to see personally or as a tooling
> implementer.

I think you're answering a different question than I asked.

One thing I've been talking about is having a path to eventually getting rid of support for .git/hooks/, on a user controlled timeline, with a smooth migration. I proposed one possible way to do that, and I was asking whether it would work okay for your use case, or whether there are problems with it (which would give me something to work with on iterating toward something that would work for you).

Your answer is "I can't prevent you", which means you don't like the proposal, but doesn't tell me what about it would not work.

Thanks, Jonathan