On Tue, Mar 22 2022, Christian Couder wrote: > 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. Agreed. FWIW this is off-list discussion between Jayati and myself which started with her asking (and this was omitted in the context that made it on list: [...] Infact, I'll be excited to work on anything you suggest even if its not related to the project, as it will help me get familiar with the codebase and the contribution process at Git. So that suggestion of mine of generalizing ref-filter.c wasn't meant to distract from the GSoC project, I understood her to be looking for suggestions for things to work on that were *not* part of the GSoC project. So I suggested that ref-filter.c task, which is orthagonal, but relates to some of the same code.