Emily Shaffer <emilyshaffer@xxxxxxxxxx> 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.
