Re: [PATCH v2] interpret-trailers: handle message without trailing newline

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 6, 2024, 15:23 UTC
Message-ID: <xmqqmskkyfep.fsf@gitster.g>
In-Reply-To: <fab48d5b-4808-439e-9384-ca4861b95edc@gmail.com>

Phillip Wood <phillip.wood123@gmail.com> writes:

Show 13 quoted lines

> Thanks for the comprehensive commit message. If the problem only affects
> "git interpret-trailers" I wonder if it would be simpler to do
>
> diff --git a/builtin/interpret-trailers.c b/builtin/interpret-trailers.c
> index 1d969494cf..e6f22459f1 100644
> --- a/builtin/interpret-trailers.c
> +++ b/builtin/interpret-trailers.c
> @@ -132,6 +132,7 @@ static void read_input_file(struct strbuf *sb, const char *file)
>                  if (strbuf_read(sb, fileno(stdin), 0) < 0)
>                          die_errno(_("could not read from stdin"));
>          }
> +        strbuf_complete_line(sb);
>  }

It is much simpler, and if we are to require a message that the user uses interpret-trailers on not to end in an incomplete line (which I do not have any objection to), it is absolutely the right approach.

With a devil's advocate hat on, though, if the trailer operation is to find the trailer on the incomplete line at the end, and insert a trailer _before_ that one, would it be more faithful to the command given by the end-user, if we inserted the new trailer without touching the existing trailer line (including its lack of terminating EOL)? Which would mean that we'd need to remember the fact that we added a LF here, and then before writing the result out make the buffer to end with an incomplete line. Which I personally think is crazy, compared to the approach to declare that a message that you subject to interpret-trailers command MUST BE a proper text, not ending with an incomplete line.

So, yeah, I like that idea.