Re: [PATCH v3 0/9] Trailer readability cleanups

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 22, 2023, 22:47 UTC
Message-ID: <xmqq8r8xyge6.fsf@gitster.g>
In-Reply-To: <pull.1563.v3.git.1695412245.gitgitgadget@gmail.com>

"Linus Arver via GitGitGadget" <gitgitgadget@gmail.com> writes:

Show 8 quoted lines

> These patches were created while digging into the trailer code to better
> understand how it works, in preparation for making the trailer.{c,h} files
> as small as possible to make them available as a library for external users.
> This series was originally created as part of [1], but are sent here
> separately because the changes here are arguably more subjective in nature.
> I think Patch 1 is the most important in this series. The others can wait,
> if folks are opposed to adding them on their own merits at this point in
> time.

Hmph, as we discussed, these changes have already been cooking in 'next' for some time:

    13211ae23f trailer: separate public from internal portion of trailer_iterator
    c2a8edf997 trailer: split process_input_file into separate pieces
    94430d03df trailer: split process_command_line_args into separate functions
    ee8c5ee08c trailer: teach find_patch_start about --no-divider
    d2be104085 trailer: rename *_DEFAULT enums to *_UNSPECIFIED
    b5e75f87b5 trailer: use offsets for trailer_start/trailer_end

and I thought we agreed that we'll park them in 'next' and do whatever necessary fix-up on top as incremental patches? The first three patches in this iteration seems to be identical to the previous round, so I can ignore them and keep the old iteration, but the remainder of this series are replacements that are suitable when the series was still out of 'next', but they are no longer usable once the series is in 'next'.

I could revert and discard [4-6/6] of the previous iteration out of 'next' and have only the first three (which I thought have been adequately reviewed without remaining issues) graduate to 'master', if it makes it easier to fix this update on top, but I'd rather not to encourage people to form a habit of reverting changes out of 'next'.

Thanks.