Emily Shaffer <emilyshaffer@xxxxxxxxxx> writes:
> An implementation of the first piece of the proposal given in
> lore.kernel.org/git/20191116011125.GG22855@xxxxxxxxxx.
>
> Teaches a new command, 'git hook', which will someday include 'git hook
> --add ...', 'git hook --edit ...', and maybe more. For now, just teach
> it how to check the config files with 'git hook --list ...'.
>
> The hooks-to-run list is collected in a new library, hook.o, which can
> someday reimplement find_hook() or otherwise be invoked to run all hooks
> for a given hookname (e.g. "pre-commit").
Nice to see the endgame vision upfront.
A few things that I'd like to see in the endgame that you did not
mention here are:
- We may probably not want to have an authoritative "these are the
hooks Git runs" catalog, so it would be great if the resulting
system can operate without one.
- There are at least two kinds of hooks wrt the style of input they
take. Some take their input on their command line, which makes
it quite easy to run multiple of them in a row. Others take
their input from their standard input stream, which probably
means that there needs a cache of the input stream to feed to
each such hook script (unless Git process itself is generating
the stream to drive the hook, in which case we could run the
generation of the stream multiple times) if we want to run
multiple of them.
. With the design goal of *not* having an authoritiative catalog,
we'd probably need some way to annotate each entry in the [hook]
configuration which kind of invication the hook program wants.
. There may be more than the above two styles. The system should
be designed to be extensible to accomodate yet more.
Thanks.
