Re: [PATCH] bugreport: collect list of populated hooks
- From
Emily Shaffer <emilyshaffer@google.com>
- Date
- Apr 27, 2020, 19:02 UTC
- Message-ID
- <20200427190257.GA77802@google.com>
- In-Reply-To
- <xmqqsggs9ngo.fsf@gitster.c.googlers.com>
On Fri, Apr 24, 2020 at 09:52:07PM -0700, Junio C Hamano wrote:
Show 13 quoted lines
> > Emily Shaffer <emilyshaffer@google.com> 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.
Show 17 quoted lines
>
> > @@ -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@google.com 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