On Mon, Jul 24, 2023 at 10:29:52AM -0700, Junio C Hamano wrote:
> Kousik Sanagavarapu <five231003@xxxxxxxxx> 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.
> > 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@xxxxxxxxx>
> > Mentored-by: Christian Couder <christian.couder@xxxxxxxxx>
> > Mentored-by: Hariom Verma <hariom18599@xxxxxxxxx>
> > Signed-off-by: Kousik Sanagavarapu <five231003@xxxxxxxxx>
> > ---
> > 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
