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

Emily Shaffer [off-list ref] writes:

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.