"Linus Arver via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes: > This patch series is the first 9 patches of a larger cleanup/bugfix series > (henceforth "larger series") I've been working on. The main goal of this > series is to begin the process of "libifying" the trailer API. By "API" I > mean the interface exposed in trailer.h. The larger series brings a number > of additional cleanups (exposing and fixing some bugs along the way), and > builds on top of this series. > > When the larger series is merged, we will be in a good state to additionally > pursue the following goals: > > 1. "API reuse inside Git": make the API expressive enough to eliminate any > need by other parts of Git to use the interpret-trailers builtin as a > subprocess (instead they could just use the API directly); > 2. "API stability": add unit tests to codify the expected behavior of API > functions; and > 3. "API documentation": create developer-focused documentation to explain > how to use the API effectively, noting any API limitations or > anti-patterns. > > In the future after libification is "complete", users external to Git will > be able to use the same trailer processing API used by the > interpret-trailers builtin. For example, a web server may want to parse > trailers the same way that Git would parse them, without having to call > interpret-trailers as a subprocess. This use case was the original > motivation behind my work in this area. > > With the libification-focused goals out of the way, let's turn to this patch > series in more detail. > > In summary this series breaks up "process_trailers()" into smaller pieces, > exposing many of the parts relevant to trailer-related processing in > trailer.h. This will force us to eventually introduce unit tests for these > API functions, but that is a good thing for API stability. We also perform > some preparatory refactors in order to help us unify the trailer formatting > machinery toward the end of this series. > > > Notable changes in v6 > ===================== > > * Mainly wording changes to commit messages. Thanks to Christian for the > suggestions. It's been nearly a week since this was posted. Any more comments, or is everybody happy with this iteration? Otherwise I am tempted to mark the topic for 'next' soon. Thanks.