Re: [PATCH v3 4/6] hook: allow running non-native hooks

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 27, 2021, 00:22 UTC
Message-ID: <xmqq7dg7d9dc.fsf@gitster.g>
In-Reply-To: <YSgatN5kYwLJtDMQ@google.com>

Emily Shaffer <emilyshaffer@google.com> writes:

Show 5 quoted lines

> I think it's A) pretty important to make it easy for users to run
> whatever not-necessarily-git-native hook they want, and B) useful for
> script Git commands to take advantage of the typo check. So, I'll add a
> `--enforce-known-hookname` (or maybe a better named one, this isn't my
> strong suit) and switch git-send-email and friends to use it.

I somehow feel this is backwards.

Once you write the invocation of "git hook run <hookname>" into your script and tested it, there is no further need for typo checking.

What's the use case you are trying to help with typo checking? When a script takes a hookname from the user and runs "git hook run $1", then passing --this-must-be-a-known-hook option that errors out when the named hook does not exist and unrecognised (there is no need to error out if a hook with unusual name the user gave us does exist---the user asked us to run it, so we just can run it) might make sense. But I am somehow not getting the sense that it is the expected use case you are worried about.

If the reason why you are making the typo-checking an opt-in feature is because you want to allow users to run "git hook run" with minimum typing, I suspect that you may be optimizing for a wrong case. Interactive users are the ones that benefit from typo-checking the most, and if they are interactive (as opposed to being a script), they are flexible enough not to say "git hook run foobar" when they know foobar does not exist and they know foobar is not a generally accepted hook, no? So, I think it makes more sense to by default allow a hook with a recognizable name to be missing, but complain when a randomly named hook is missing, and to have an option that permits a hook to be unrecognised and missing.