From: Phillip Wood <phillip.wood123@gmail.com>
To: Li Chen <me@linux.beauty>,
phillipwood <phillip.wood@dunelm.org.uk>,
git <git@vger.kernel.org>, Junio C Hamano <gitster@pobox.com>,
Kristoffer Haugsbakk <kristofferhaugsbakk@fastmail.com>
Subject: Re: [PATCH v5 01/29] trailer: append trailers in-process and drop the fork to `interpret-trailers`
Date: Thu, 23 Oct 2025 14:21:28 +0100 [thread overview]
Message-ID: <7d12b046-365f-441c-af8e-8a39d61efbbd@gmail.com> (raw)
In-Reply-To: <20251022053951.602605-2-me@linux.beauty>
Hi Li
On 22/10/2025 06:39, Li Chen wrote:
> From: Li Chen <chenl311@chinatelecom.cn>
>
> Route all trailer insertion through trailer_process() and make
> builtin/interpret-trailers just do file I/O before calling into it.
> amend_file_with_trailers() now shares the same code path.
>
> This removes the fork/exec and tempfile juggling, cutting overhead and
> simplifying error handling. No functional change. It also
> centralizes logic to prepare for follow-up rebase --trailer patch.
>
> Signed-off-by: Li Chen <chenl311@chinatelecom.cn>
When I review v3 of this series I said
>> As I said above reusing the existing code as you have done here is a
>> much better approach. However it would be much easier to review if
>> the code movement was separated from the refactoring. I'm also
>> struggling to see the benefit of a lot of the refactoring - I was
>> expecting the conversion to use an strubf would essentially look like
>> fwrite() being replaced with strbuf_add() and fprintf() being
>> replaced with strbuf_addf() etc. rather than reworking the logic.
Unfortunately this version has the same code changes as v3 that make it
are virtually impossible to verify if the behavior is changed or not.
The diff below shows what I was hoping to see as the first step. It
refactors interpret_trailers() in place to factor out the code that
processes the trailers into a separate function. That makes it easy to
see that fwrite() is replaced with strbuf_add() etc. and so verify that
the behavior is unchanged. If you view the diff with "--color-moved"
you'll see that virtually all of the code in the new
interpret_trailers() function is moved from the old one which in turn
makes it easy to verify that there is no change in behavior. I would
expect the next patch in the series to move the new function for
processing trailers into trailer.c and the patch after that to refactor
amend_file_with_trailers() to add and use amend_strbuf_with_trailers()
and stop forking "git interpret-trailers". Then builtin/rebase.c can be
modified to add support for trailers using amend_strbuf_with_trailers().
Thanks
Phillip
---- 8< ----
diff --git a/builtin/interpret-trailers.c b/builtin/interpret-trailers.c
index 41b0750e5af..4c90580ffff 100644
--- a/builtin/interpret-trailers.c
+++ b/builtin/interpret-trailers.c
@@ -136,32 +136,21 @@ static void read_input_file(struct strbuf *sb, const char *file)
strbuf_complete_line(sb);
}
-static void interpret_trailers(const struct process_trailer_options *opts,
- struct list_head *new_trailer_head,
- const char *file)
+static void process_trailers(const struct process_trailer_options *opts,
+ struct list_head *new_trailer_head,
+ struct strbuf *sb, struct strbuf *out)
{
LIST_HEAD(head);
- struct strbuf sb = STRBUF_INIT;
- struct strbuf trailer_block_sb = STRBUF_INIT;
struct trailer_block *trailer_block;
- FILE *outfile = stdout;
-
- trailer_config_init();
-
- read_input_file(&sb, file);
-
- if (opts->in_place)
- outfile = create_in_place_tempfile(file);
-
- trailer_block = parse_trailers(opts, sb.buf, &head);
+
+ trailer_block = parse_trailers(opts, sb->buf, &head);
/* Print the lines before the trailer block */
if (!opts->only_trailers)
- fwrite(sb.buf, 1, trailer_block_start(trailer_block), outfile);
+ strbuf_add(out, sb->buf, trailer_block_start(trailer_block));
if (!opts->only_trailers && !blank_line_before_trailer_block(trailer_block))
- fprintf(outfile, "\n");
-
+ strbuf_addch(out, '\n');
if (!opts->only_input) {
LIST_HEAD(config_head);
@@ -173,22 +162,40 @@ static void interpret_trailers(const struct process_trailer_options *opts,
}
/* Print trailer block. */
- format_trailers(opts, &head, &trailer_block_sb);
+ format_trailers(opts, &head, out);
free_trailers(&head);
- fwrite(trailer_block_sb.buf, 1, trailer_block_sb.len, outfile);
- strbuf_release(&trailer_block_sb);
/* Print the lines after the trailer block as is. */
if (!opts->only_trailers)
- fwrite(sb.buf + trailer_block_end(trailer_block), 1,
- sb.len - trailer_block_end(trailer_block), outfile);
+ strbuf_add(out, sb->buf + trailer_block_end(trailer_block),
+ sb->len - trailer_block_end(trailer_block));
trailer_block_release(trailer_block);
-
+}
+
+static void interpret_trailers(const struct process_trailer_options *opts,
+ struct list_head *new_trailer_head,
+ const char *file)
+{
+ struct strbuf sb = STRBUF_INIT;
+ struct strbuf out = STRBUF_INIT;
+ FILE *outfile = stdout;
+
+ trailer_config_init();
+
+ read_input_file(&sb, file);
+
+ if (opts->in_place)
+ outfile = create_in_place_tempfile(file);
+
+ process_trailers(opts, new_trailer_head, &sb, &out);
+
+ fwrite(out.buf, out.len, 1, outfile);
if (opts->in_place)
if (rename_tempfile(&trailers_tempfile, file))
die_errno(_("could not rename temporary file to %s"), file);
strbuf_release(&sb);
+ strbuf_release(&out);
}
int cmd_interpret_trailers(int argc,
next prev parent reply other threads:[~2025-10-23 13:21 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-22 5:39 [PATCH v5 00/29] rebase: support --trailer Li Chen
2025-10-22 5:39 ` [PATCH v5 01/29] trailer: append trailers in-process and drop the fork to `interpret-trailers` Li Chen
2025-10-23 13:21 ` Phillip Wood [this message]
2025-11-04 11:53 ` Li Chen
2025-10-22 5:39 ` [PATCH v5 02/29] trailer: restore interpret_trailers helper Li Chen
2025-10-22 5:39 ` [PATCH v5 03/29] trailer: drop --trailer prefix handling in amend helper Li Chen
2025-10-22 5:39 ` [PATCH v5 04/29] trailer: move config_head and arg_head to if storage Li Chen
2025-10-22 5:39 ` [PATCH v5 05/29] trailer: use bool for had_trailer_before Li Chen
2025-10-22 5:39 ` [PATCH v5 06/29] interpret-trailers: buffer stdout output Li Chen
2025-10-22 5:39 ` [PATCH v5 07/29] trailer: mirror interpret-trailers output flow Li Chen
2025-10-22 5:39 ` [PATCH v5 08/29] trailer: handle trailer append failures gently Li Chen
2025-10-22 5:39 ` [PATCH v5 09/29] rebase: support --trailer Li Chen
2025-10-23 13:21 ` Phillip Wood
2025-10-22 5:39 ` [PATCH v5 10/29] rebase: inline trailer state paths Li Chen
2025-10-22 5:39 ` [PATCH v5 11/29] rebase: reuse buffer for trailer args Li Chen
2025-10-22 5:39 ` [PATCH v5 12/29] rebase: drop redundant strbuf_release call Li Chen
2025-10-22 5:39 ` [PATCH v5 13/29] rebase: skip stripping of --trailer option prefix Li Chen
2025-10-22 5:39 ` [PATCH v5 14/29] rebase: die on invalid trailer args Li Chen
2025-10-22 5:39 ` [PATCH v5 15/29] rebase: validate trailers with configured separators Li Chen
2025-10-22 5:39 ` [PATCH v5 16/29] sequencer: add trailers to message before writing file Li Chen
2025-10-22 5:39 ` [PATCH v5 17/29] t3440: create expect files at point of use Li Chen
2025-10-22 5:39 ` [PATCH v5 18/29] t3440: check apply backend error includes option Li Chen
2025-10-22 5:39 ` [PATCH v5 19/29] t3440: use test_commit_message for trailer checks Li Chen
2025-10-22 5:39 ` [PATCH v5 20/29] t3440: drop redundant resets and pass branch to rebase where needed Li Chen
2025-10-22 5:39 ` [PATCH v5 21/29] t3440: assert trailer on HEAD after conflict rebase Li Chen
2025-10-22 5:39 ` [PATCH v5 22/29] rebase: persist --trailer options across restarts Li Chen
2025-10-22 5:39 ` [PATCH v5 23/29] t3440: remove redundant --keep-empty Li Chen
2025-10-22 5:39 ` [PATCH v5 24/29] t3440: use helper for trailer checks Li Chen
2025-10-22 5:39 ` [PATCH v5 25/29] t3440: test --trailer without values Li Chen
2025-10-22 5:39 ` [PATCH v5 26/29] t3440: convert ex.com to example.com Li Chen
2025-10-22 5:39 ` [PATCH v5 27/29] t3440: ensure trailers persist after rebase continue Li Chen
2025-10-22 5:39 ` [PATCH v5 28/29] t3440: exercise trailer config mapping Li Chen
2025-10-22 5:39 ` [PATCH v5 29/29] sequencer: honor --trailer with fixup -C Li Chen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7d12b046-365f-441c-af8e-8a39d61efbbd@gmail.com \
--to=phillip.wood123@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=kristofferhaugsbakk@fastmail.com \
--cc=me@linux.beauty \
--cc=phillip.wood@dunelm.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox