Re: [PATCH v4 1/2] ref-filter: add multiple-option parsing functions

From: Kousik Sanagavarapu <five231003@gmail.com>
Date: Jul 24, 2023, 18:12 UTC
Message-ID: <ZL6_DlDIE8Hfl_T6@five231003>
In-Reply-To: <xmqqa5vlqktr.fsf@gitster.g>

On Mon, Jul 24, 2023 at 10:29:52AM -0700, Junio C Hamano wrote:

Show 28 quoted lines

> Kousik Sanagavarapu <five231003@gmail.com> writes:
> 
> > The functions
> >
> > 	match_placeholder_arg_value()
> > 	match_placeholder_bool_arg()
> >
> > were added in pretty 4f732e0fd7 (pretty: allow %(trailers) options
> > with explicit value, 2019-01-29) to parse multiple options in an
> > argument to --pretty. For example,
> >
> > 	git log --pretty="%(trailers:key=Signed-Off-By,separator=%x2C )"
> >
> > will output all the trailers matching the key and seperates them by
> > a comma followed by a space per commit.
> >
> > Add similar functions,
> >
> > 	match_atom_arg_value()
> > 	match_atom_bool_arg()
> >
> > in ref-filter.
> 
> What are their similarities, and in what way are they different?  If
> they are similar enough, is it reasonable to allow these two pairs
> of helpers to share code (the best case would be we can just call
> the existing ones, possibly changing their names to more suitable
> ones that fit their now-more-general-purpose nature better)?

What do you mean by "share code"?

They are similar in their functionality, that is parsing the option and grabbing the value (if the option has a value, otherwise we do what we did here). The difference is the way we do such a parsing.

In pretty, we directly skip_prefix() the placeholder. So we check for ')' to see if we have reached the end of "to_parse".

In ref-filter (the current patches), we deal directly with the options ("arg" here), that is we can't do a check for ')' to see if we have exhausted our option list. So we can't really use the same functions, but there is the possiblity that we can modify them to be used here too.

So the difference is mainly just how we send "to_parse" and how we want it parsed.

Show 18 quoted lines

> > There is no atom yet that can use these functions in ref-filter, but we
> > are going to add a new %(describe) atom in a subsequent commit where we
> > parse options like tags=<bool-value> or match=<pattern> given to it.
> >
> > Helped-by: Junio C Hamano <gitster@pobox.com>
> > Mentored-by: Christian Couder <christian.couder@gmail.com>
> > Mentored-by: Hariom Verma <hariom18599@gmail.com>
> > Signed-off-by: Kousik Sanagavarapu <five231003@gmail.com>
> > ---
> >  ref-filter.c | 105 +++++++++++++++++++++++++++++++++++++++++++++++++++
> >  1 file changed, 105 insertions(+)
> 
> Asking just out of curiousity, all patches from you seem to have
> "Mentored-by" naming your mentors, but how deeply involved are they
> in each patch you send out?  Is it like you first ask them to review
> and only after addressing the issues their reviews raise, you are
> sending the polished patches to the list?  Or are they not deeply
> involved in the code but offering suggestions on the design

Both actually, the code and the design. I send them the commits which I push to my fork and they take a look on the code as well as the design and offer suggestions on how both can be improved or re-did.

> (I am
> curious what their reactions were on your design decision to
> add the two helper functions)?

They suggested doing something similar to what you suggested above but it is kind of on hold (also because of how we changed the implementation of "match_atom_arg_value()"). Now that you bring it up, should this patch be reworked?

Thanks