TL;DR: I'm working on a new approach.
Junio C Hamano <gitster@xxxxxxxxx> writes:
> Other than that, I didn't find anything quesionable in any of the
> patches in this round. Looking good.
So actually, I'm now taking a much more aggressive approach to libifying
the trailer subsystem. Instead of incrementally simplifying/improving
things as in this series, I think I need to get to the root problem,
which is that the trailer.h API isn't rich enough to make it pleasant
for clients to use, including our own builtin/interpret-trailers.c
client. That is, the problem we have today is that the trailer subsystem
is not very ergonomic for internal use, much less external use (outside
of Git itself).
As an example, the current API exposes process_trailers() which does a
whole bunch of things that only builtin/interpret-trailers.c cares
about. Multiple other clients of trailer.h exist in our codebase (e.g.,
sequencer.c, pretty.c, ref-filter.c) but none of them use
process_trailers().
One really useful data structure is the trailer_iterator that was
introduced in f0939a0eb1 (trailer: add interface for iterating over
commit trailers, 2020-09-27). The only problem is that it is not generic
enough such that interpret-trailers.c can use it.
My new goal is to introduce a new API in trailer.h so that
interpret-trailers.c and everyone else can start using these new data
structures and associated functions (while preserving the
trailer_iterator interface). So the order of operations should be:
(1) enrich the trailer API (make trailer.h have simpler data structures
and practical functions that clients can readily use), and
(2) make builtin/interpret-trailers.c, and other clients in the Git
codebase use this new API.
This way when the unit test framework selection process is finalized we
can
(3) write unit tests for the functions in the (enriched) trailer API,
which is one of the major goals for my efforts around this area.
The work I've started locally for (1) does not depend on this series,
and I think it'll be cleaner (less churn) that way. So, feel free to
drop this series in favor of the forthcoming work described in this
message.
Thanks.
