Aaron Schrab <aa...@schrab.com> writes:
> Create find_hook() function to determine if a given hook exists and is
> executable. If it is the path to the script will be returned, otherwise
> NULL is returned.
Sounds like a sensible thing to do. To make sure the API is also
sensible, all the existing hooks should be updated to use this API,
> This is in support for an upcoming run_hook_argv() function which will
> expect the full path to the hook script as the first element in the
There is currently a public function called run_hook() that squats
on the good name with a kludgy API that is too specific to using
separate index file. Back when it was a private helper in the
implementation of "git commit", it was perfectly fine, but it was
exported without giving much thought on the API.
If you are introducing a new run_hook_* function, give it a generic
enough API that lets all the existing hook callers to use it. I
would imagine that the API requirement may be modelled after
run_command() API so that we can pass argv and tweak the hook's
environ, as well as feeding its stdin and possibly reading from
its stdout. That would be very useful.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html