Phillip Wood <phillip.wood123@xxxxxxxxx> writes:
> 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.
