On Sun, Mar 20, 2022 at 8:14 PM Jayati Shrivastava <gaurijove@xxxxxxxxx> wrote: > > On Sat, Mar 19, 2022 at 9:49 PM Ævar Arnfjörð Bjarmason > <avarab@xxxxxxxxx> wrote: > > > > > > One thing I'd *really* like to see is the bits of %(if) %(then) > > etc. extracted from ref-filter.c into some general API other commands > > could use with strbuf_expand() and friends. > > > > I.e. if you could in addition to the strbuf_expand() callback define > > what verbs you support for "if" and the like, or have callbacks for > > their comparison functions. > > > > Then have that machinery drive the whole format expansion, which > > eventually would expand your %(some-custom-thing) via a callback. > > > > I.e. the whole "valid_atom" state machine in ref-filter.c. > > So, the end goal is to design a formatting API that can be used by any > command that takes --format option? It might be nice if we get closer to this after your GSoC project, but I don't think it should become the main goal of the GSoC. > Previous interns worked on > unifying pretty.c and cat-file.c with ref-filter.c and so the next task can > be to extend "valid_atom" state machine to work with more commands. Note that performance issues have been a really big issue in unifying cat-file.c with ref-filter.c. > Do you have any suggestions for new atoms/verbs I could add > support for or any such similar small exercise to start with? It would be nice if we first got an idea of the features in pretty.c that do not yet have something similar in ref-filter.c. I think Hariom used to show how features in pretty.c corresponded to features in ref-filter.c, and this helped with deciding about the next steps to take.
