git/trailer.h, branch jch

commit, tag: parse --trailer with OPT_STRVEC

2026-03-06T21:02:20Z

Now that amend_file_with_trailers() expects raw trailer lines, do not store argv-style "--trailer=" strings in git commit and git tag. Parse --trailer using OPT_STRVEC so trailer_args contains only the trailer value, and drop the temporary prefix stripping in amend_file_with_trailers(). Signed-off-by: Li Chen Signed-off-by: Junio C Hamano

trailer: append trailers without fork/exec

2026-03-06T21:02:20Z

Introduce amend_strbuf_with_trailers() to apply trailer additions to a message buffer via process_trailers(), avoiding the need to run git interpret-trailers as a child process. Update amend_file_with_trailers() to use the in-process helper and rewrite the target file via tempfile+rename, preserving the previous in-place semantics. As the trailers are no longer added in a separate process and trailer_config_init() die()s on missing config values it is called early on in cmd_commit() and cmd_tag() so that they die() early before writing the message file. The trailer arguments are now also sanity checked. Keep existing callers unchanged by continuing to accept argv-style --trailer= entries and stripping the prefix before feeding the in-process implementation. Signed-off-by: Li Chen Signed-off-by: Phillip Wood Signed-off-by: Junio C Hamano

trailer: libify a couple of functions

2026-03-06T21:02:19Z

Move create_in_place_tempfile() and process_trailers() from builtin/interpret-trailers.c into trailer.c and expose it via trailer.h. This reverts most of ae0ec2e0e0b (trailer: move interpret_trailers() to interpret-trailers.c, 2024-03-01) and lets other call sites reuse the same trailer rewriting logic. Signed-off-by: Li Chen Signed-off-by: Phillip Wood Signed-off-by: Junio C Hamano

trailer: spread usage of "trailer_block" language

2024-10-14T16:33:02Z

Deprecate the "trailer_info" struct name and replace it with "trailer_block". This is more readable, for two reasons: 1. "trailer_info" on the surface sounds like it's about a single trailer when in reality it is a collection of one or more trailers, and 2. the "*_block" suffix is more informative than "*_info", because it describes a block (or region) of contiguous text which has trailers in it, which has been parsed into the trailer_block structure. Rename the size_t trailer_block_start, trailer_block_end; members of trailer_info to just "start" and "end". Rename the "info" pointer to "trailer_block" because it is more descriptive. Update comments accordingly. Signed-off-by: Linus Arver Signed-off-by: Taylor Blau

Merge branch 'la/hide-trailer-info'

2024-05-23T18:04:27Z

The trailer API has been reshuffled a bit. * la/hide-trailer-info: trailer unit tests: inspect iterator contents trailer: document parse_trailers() usage trailer: retire trailer_info_get() from API trailer: make trailer_info struct private trailer: make parse_trailers() return trailer_info pointer interpret-trailers: access trailer_info with new helpers sequencer: use the trailer iterator trailer: teach iterator about non-trailer lines trailer: add unit tests for trailer iterator Makefile: sort UNIT_TEST_PROGRAMS

builtin/commit: refactor --trailer logic

2024-05-07T17:06:03Z

git-commit adds user trailers to the commit message by passing its `--trailer` arguments to a child process running `git-interpret-trailers --in-place`. This logic is broadly useful, not just for git-commit but for other commands constructing message bodies (e.g. git-tag). Let's move this logic from git-commit to a new function in the trailer API, so that it can be re-used in other commands. Helped-by: Patrick Steinhardt Helped-by: Junio C Hamano Signed-off-by: John Passaro Acked-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

trailer: document parse_trailers() usage

2024-05-02T16:57:08Z

Explain how to use parse_trailers(), because earlier we made the trailer_info struct opaque. That is, because clients can no longer peek inside it, we should give them guidance about how the (pointer to the) opaque struct can still be useful to them. Rename "head" struct to "trailer_objects" to make the wording of the new comments a bit easier to read (because "head" itself doesn't really have any domain-specific meaning here). Signed-off-by: Linus Arver Signed-off-by: Junio C Hamano

trailer: retire trailer_info_get() from API

2024-05-02T16:57:08Z

Make trailer_info_get() "static" to be file-scoped to trailer.c, because no one outside of trailer.c uses it. Remove its declaration from . We have to also reposition it to be above parse_trailers(), which depends on it. Signed-off-by: Linus Arver Signed-off-by: Junio C Hamano

trailer: make trailer_info struct private

2024-05-02T16:57:08Z

In 13211ae23f (trailer: separate public from internal portion of trailer_iterator, 2023-09-09) we moved trailer_info behind an anonymous struct to discourage use by trailer.h API users. However it still left open the possibility of external use of trailer_info itself. Now that there are no external users of trailer_info, we can make this struct private. Make this struct private by putting its definition inside trailer.c. This has two benefits: (1) it makes the surface area of the public facing interface (trailer.h) smaller, and (2) external API users are unable to peer inside this struct (because it is only ever exposed as an opaque pointer). There are a few disadvantages: (A) every time the member of the struct is accessed an extra pointer dereference must be done, and (B) for users of trailer_info outside trailer.c, this struct can no longer be allocated on the stack and may only be allocated on the heap (because its definition is hidden away in trailer.c) and appropriately deallocated by the user, and (C) without good documentation on the API, the opaque struct is hostile to programmers by going opposite to the "Show me your data structures, and I won't usually need your code; it'll be obvious." mantra [2]. (The disadvantages have already been observed in the two preparatory commits that precede this one.) This commit believes that the benefits outweigh the disadvantages for designing APIs, as explained below. Making trailer_info private exposes existing deficiencies in the API. This is because users of this struct had full access to its internals, so there wasn't much need to actually design it to be "complete" in the sense that API users only needed to use what was provided by the API. For example, the location of the trailer block (start/end offsets relative to the start of the input text) was accessible by looking at these struct members directly. Now that the struct is private, we have to expose new API functions to allow clients to access this information (see builtin/interpret-trailers.c). The idea in this commit to hide implementation details behind an "opaque pointer" is also known as the "pimpl" (pointer to implementation) idiom in C++ and is a common pattern in that language (where, for example, abstract classes only have pointers to concrete classes). However, the original inspiration to use this idiom does not come from C++, but instead the book "C Interfaces and Implementations: Techniques for Creating Reusable Software" [1]. This book recommends opaque pointers as a good design principle for designing C libraries, using the term "interface" as the functions defined in *.h (header) files and "implementation" as the corresponding *.c file which define the interfaces. The book says this about opaque pointers: ... clients can manipulate such pointers freely, but they can’t dereference them; that is, they can’t look at the innards of the structure pointed to by them. Only the implementation has that privilege. Opaque pointers hide representation details and help catch errors. In our case, "struct trailer_info" is now hidden from clients, and the ways in which this opaque pointer can be used is limited to the richness of . In other words, exclusively controls exactly how "trailer_info" pointers are to be used. [1] Hanson, David R. "C Interfaces and Implementations: Techniques for Creating Reusable Software". Addison Wesley, 1997. p. 22 [2] Raymond, Eric S. "The Cathedral and the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary". O'Reilly, 1999. Helped-by: Junio C Hamano Helped-by: Christian Couder Signed-off-by: Linus Arver Signed-off-by: Junio C Hamano

trailer: make parse_trailers() return trailer_info pointer

2024-05-02T16:57:08Z

This is the second and final preparatory commit for making the trailer_info struct private to the trailer implementation. Make trailer_info_get() do the actual work of allocating a new trailer_info struct, and return a pointer to it. Because parse_trailers() wraps around trailer_info_get(), it too can return this pointer to the caller. From the trailer API user's perspective, the call to trailer_info_new() can be replaced with parse_trailers(); do so in interpret-trailers. Because trailer_info_new() is no longer called by interpret-trailers, remove this function from the trailer API. With this change, we no longer allocate trailer_info on the stack --- all uses of it are via a pointer where the actual data is always allocated at runtime through trailer_info_new(). Make trailer_info_release() free this dynamically allocated memory. Finally, due to the way the function signatures of parse_trailers() and trailer_info_get() have changed, update the callsites in format_trailers_from_commit() and trailer_iterator_init() accordingly. Helped-by: Christian Couder Signed-off-by: Linus Arver Signed-off-by: Junio C Hamano