Phillip Wood <phillip.wood123@xxxxxxxxx> writes: >> If you want to refer to commands in ordering options (like your >> "before"), then you'd have to refer to their names. For "my-command" >> that's not too bad. For the longer one, it's a bit awkward. You _could_ >> do: >> >> hookcmd.my-command.before = git diff --check --cached >> >> which is the same number of lines as yours. But I'd probably give it a >> name, like: >> >> hookcmd.check-whitespace.command = git diff --check --cached >> hookcmd.my-command.before = check-whitespace >> >> That's one more line than yours, but I think it separates the concerns >> more clearly. And it extends naturally to more options specific to >> check-whitespace. > > I agree that using a name rather than the command line makes things > clearer here True. These ways call for a different attitude to deal with errors compared to the approach to order them with numbers, though. If your approach is to order by number attached to each hook, only possible errors you'd need to worry about are (1) what to do when the user forgets to give a number to a hook and (2) what to do when the user gives the same number by accident to multiple hooks, and both can even be made non-errors by declaring that an unnumbered hook has a default number, and that two hooks with the same number execute in an unspecified and unstable order. On the other hand, the approach to specify relative ordering among hooks can break more easily. E.g. when a hook that used to be before "my-command" got removed. It is harder to find a "sensible" default behaviour for such situations. I am perfectly fine with having more possible error cases than allowing misconfigured system to silently do a wrong thing, so...
