Re: [PATCH v5 2/3] trailer: find the end of the log message

TL;DR: I'm working on a new approach.

Junio C Hamano <gitster@pobox.com> writes:

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.