From: Phillip Wood <phillip.wood123@gmail.com>
To: Li Chen <me@linux.beauty>,
Kristoffer Haugsbakk <kristofferhaugsbakk@fastmail.com>
Cc: Phillip Wood <phillip.wood@dunelm.org.uk>,
git <git@vger.kernel.org>, Junio C Hamano <gitster@pobox.com>
Subject: Re: [PATCH v4 17/29] tests: t3440: create expect files at point of use
Date: Thu, 23 Oct 2025 10:04:34 +0100 [thread overview]
Message-ID: <bdba181a-915b-48d7-8e24-84fd08436576@gmail.com> (raw)
In-Reply-To: <199e82ac06b.22809060320824.5985600477588171363@linux.beauty>
On 15/10/2025 14:58, Li Chen wrote:
> Hi Kristoffer,
>
> Thanks for the review suggestions! I'll address them in the next version.
>
> ---- On Wed, 15 Oct 2025 04:41:33 +0800 Kristoffer Haugsbakk <kristofferhaugsbakk@fastmail.com> wrote ---
> > Now you start to change the test suite/file that you created for this
> > series. There shouldn’t be a need to do a test file-only patch/commit
> > for a fresh series.
> >
> > I saw in one of your patches that you removed `--keep-empty` from a test
> > because “that is the default”. I also saw Phillip’s comment somewhere
> > that said the same thing.
> >
> > The goal with maturing series is not to add patches on top in each round
> > (if that’s what you are doing). It is to recreate them as if the series
> > was perfectly written to begin with; if one patch introduces
> > `--trailers` and a test file, then there should be no need with
> > follow-up patches that improve the test file style, refactors it, and
> > so on.
>
> Thanks for the tip. I split the changes into separate commits to ease review,
> as Phillip suggested in https://lore.kernel.org/git/d4c9f082-52be-48d9-b817-fcb8a72e1bd7@gmail.com/.
>
> It seems I may have overdone it? If so, I'll try for a better balance in the next version.
I asked that you did not refactor code at the same time as you moved it.
I was expecting a handful of patches, not twenty-nine. The point that
Kristoffer makes about this patch is perfectly valid - you add a new
test and then correct it in a later patch. Instead you should correct
the test where it is introduced as Kirstoffer suggested. Looking at the
first patch in this series there seems to have been some
miscommunication because it has exactly the same problem as V3. The code
that is moved from builtin/interpret-trailers.c to trailer.c is heavily
refactored at the same time. Variable names are changed and the code is
rearranged so that "git diff --color-moved
--color-moved-ws=ignore-indentation-change" detects barely any moved
lines. I'll try and leave some more detailed feedback on the first few
patches of V5 in the next few days.
Thanks
Phillip
next prev parent reply other threads:[~2025-10-23 9:04 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-14 12:24 [PATCH v4 00/29] rebase: support --trailer Li Chen
2025-10-14 12:24 ` [PATCH v4 01/29] trailer: append trailers in-process and drop the fork to `interpret-trailers` Li Chen
2025-10-14 20:43 ` Kristoffer Haugsbakk
2025-10-21 9:57 ` Li Chen
2025-10-14 12:24 ` [PATCH v4 02/29] trailer: restore interpret_trailers helper Li Chen
2025-10-14 12:24 ` [PATCH v4 03/29] trailer: drop --trailer prefix handling in amend helper Li Chen
2025-10-14 12:24 ` [PATCH v4 04/29] trailer: move config_head and arg_head to if storage Li Chen
2025-10-14 12:24 ` [PATCH v4 05/29] trailer: use bool for had_trailer_before Li Chen
2025-10-14 12:24 ` [PATCH v4 06/29] interpret-trailers: buffer stdout output Li Chen
2025-10-14 12:24 ` [PATCH v4 07/29] trailer: mirror interpret-trailers output flow Li Chen
2025-10-14 12:24 ` [PATCH v4 08/29] trailer: handle trailer append failures gently Li Chen
2025-10-14 12:24 ` [PATCH v4 09/29] rebase: support --trailer Li Chen
2025-10-14 20:43 ` Kristoffer Haugsbakk
2025-10-22 3:55 ` Li Chen
2025-10-14 12:24 ` [PATCH v4 10/29] rebase: inline trailer state paths Li Chen
2025-10-14 12:24 ` [PATCH v4 11/29] rebase: reuse buffer for trailer args Li Chen
2025-10-14 12:24 ` [PATCH v4 12/29] rebase: drop redundant strbuf_release call Li Chen
2025-10-14 12:24 ` [PATCH v4 13/29] rebase: skip stripping of --trailer option prefix Li Chen
2025-10-14 12:24 ` [PATCH v4 14/29] rebase: die on invalid trailer args Li Chen
2025-10-14 12:24 ` [PATCH v4 15/29] rebase: validate trailers with configured separators Li Chen
2025-10-14 12:24 ` [PATCH v4 16/29] sequencer: add trailers to message before writing file Li Chen
2025-10-14 20:43 ` Kristoffer Haugsbakk
2025-10-14 12:24 ` [PATCH v4 17/29] tests: t3440: create expect files at point of use Li Chen
2025-10-14 20:41 ` Kristoffer Haugsbakk
2025-10-15 13:58 ` Li Chen
2025-10-15 14:02 ` Kristoffer Haugsbakk
2025-10-23 9:04 ` Phillip Wood [this message]
2025-10-28 10:26 ` Li Chen
2025-11-03 16:20 ` Phillip Wood
2025-10-14 12:24 ` [PATCH v4 18/29] tests: t3440: check apply backend error includes option Li Chen
2025-10-14 12:24 ` [PATCH v4 19/29] tests: t3440: use test_commit_message for trailer checks Li Chen
2025-10-14 12:24 ` [PATCH v4 20/29] tests: t3440: drop redundant resets and pass branch to rebase where needed Li Chen
2025-10-14 12:24 ` [PATCH v4 21/29] tests: t3440: assert trailer on HEAD after conflict rebase Li Chen
2025-10-14 12:24 ` [PATCH v4 22/29] rebase: persist --trailer options across restarts Li Chen
2025-10-14 12:24 ` [PATCH v4 23/29] tests: t3440: remove redundant --keep-empty Li Chen
2025-10-14 12:24 ` [PATCH v4 24/29] tests: t3440: use helper for trailer checks Li Chen
2025-10-14 12:24 ` [PATCH v4 25/29] tests: t3440: test --trailer without values Li Chen
2025-10-14 13:22 ` Kristoffer Haugsbakk
2025-10-14 12:24 ` [PATCH v4 26/29] tests: t3440: convert ex.com to example.com Li Chen
2025-10-14 12:24 ` [PATCH v4 27/29] tests: t3440: ensure trailers persist after rebase continue Li Chen
2025-10-14 12:24 ` [PATCH v4 28/29] tests: t3440: exercise trailer config mapping Li Chen
2025-10-14 12:24 ` [PATCH v4 29/29] sequencer: honor --trailer with fixup -C Li Chen
2025-10-14 12:31 ` [PATCH v4 00/29] rebase: support --trailer 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=bdba181a-915b-48d7-8e24-84fd08436576@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