On Fri, Apr 24, 2020 at 09:52:07PM -0700, Junio C Hamano wrote:
>
> Emily Shaffer <emilyshaffer@xxxxxxxxxx> writes:
>
> > Without a definitive list of hook names within the code, we compile our
> > own list from the documentation. This is likely prone to bitrot. To
> > reduce the amount of code humans need to read, we turn the list into a
> > string_list and iterate over it (as we are calling the same find_hook
> > operation on each string). However, since bugreport should primarily be
> > called by the user, the performance loss from massaging the string
> > seems acceptable.
>
> In this iteration we no longer are collecting the hook names into
> string list, but just formating the findings in a strbuf, no?
Right - I'll fix the commit message for round 2.
>
> > @@ -33,6 +35,53 @@ static void get_system_info(struct strbuf *sys_info)
> > get_libc_info(sys_info);
> > }
> >
> > +static void get_populated_hooks(struct strbuf *hook_info, int nongit)
> > +{
> > + /*
> > + * NEEDSWORK: Doesn't look like there is a list of all possible hooks;
> > + * so below is a transcription of `git help hooks`. Later, this should
> > + * be replaced with some programmatically generated list (generated from
> > + * doc or else taken from some library which tells us about all the
> > + * hooks)
> > + */
>
> Yes, I recall that we discussed adding some annotation to
> documentation and extracting this automatically.
Right, we did. I think I was hesitant to move on it because I had
https://lore.kernel.org/git/20200420235310.94493-1-emilyshaffer@xxxxxxxxxx
on my back burner and wasn't sure how the hook architecture would look
afterwards.
I'm not sure I know the right way to move forward (which is why I left a
NEEDSWORK) - my strongest preference is to leave it as is and wait for
the linked RFC and related work to land, at which point this code will
need a rework anyways. But if we're very interested in generating an
enum or something from the docs rather than letting this gross char**
land, I can do that too.
- Emily
