From: Junio C Hamano <gitster@pobox.com>
To: Brian Lyles <brianmlyles@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH v3] interpret-trailers: handle message without trailing newline
Date: Fri, 06 Sep 2024 09:21:27 -0700 [thread overview]
Message-ID: <xmqqy144wy60.fsf@gitster.g> (raw)
In-Reply-To: <20240906145743.2059405-1-brianmlyles@gmail.com> (Brian Lyles's message of "Fri, 6 Sep 2024 09:50:08 -0500")
Brian Lyles <brianmlyles@gmail.com> writes:
> When git-interpret-trailers is used to add a trailer to a message that
> does not end in a trailing newline, the new trailer is added on the line
> immediately following the message instead of as a trailer block
> separated from the message by a blank line.
>
> For example, if a message's text was exactly "The subject" with no
> trailing newline present, `git interpret-trailers --trailer
> my-trailer=true` will result in the following malformed commit message:
>
> The subject
> my-trailer: true
>
> While it is generally expected that a commit message should end with a
> newline character, git-interpret-trailers should not be returning an
> invalid message in this case.
I am not sure if the above example resulted in "an invalid message",
though ;-) As far as Git is concerned, a commit log can contain any
sequence of bytes.
But of course, various tools to manipulate the messages (e.g.
"commit --amend" and your editor that gets invoked by it,
"interpret-trailers") may not be prepared to see any arbitrary
bytes. I would have written
While a commit message can contain arbitrary byte sequence, the
fact that the user invoked the interpret-trailers command on it
means that the contents is expected to be a proper text, which
should not end in an incomplete line. Instead of detecting and
erroring out upon seeing such a log message, complete the last
line if it lacks the terminating LF.
or something like that, if I were working on this change.
> Use `strbuf_complete_line` to ensure that the message ends with a
> newline character when reading the input.
>
> Signed-off-by: Brian Lyles <brianmlyles@gmail.com>
> ---
>
> The range-diff from v2 is not included since the patch is so different
> that range-diff is not able to provide anything meaningful.
Very sensible.
Will queue. Thanks.
> diff --git a/t/t7513-interpret-trailers.sh b/t/t7513-interpret-trailers.sh
> index 3d3e13ccf8..d78cae3e04 100755
> --- a/t/t7513-interpret-trailers.sh
> +++ b/t/t7513-interpret-trailers.sh
> @@ -175,6 +175,46 @@ test_expect_success 'with only a title in the message' '
> test_cmp expected actual
> '
>
> +test_expect_success 'with a bodiless message that lacks a trailing newline after the subject' '
> + cat >expected <<-\EOF &&
> + area: change
> +
> + Reviewed-by: Peff
> + Acked-by: Johan
> + EOF
> + printf "area: change" |
> + git interpret-trailers --trailer "Reviewed-by: Peff" \
> + --trailer "Acked-by: Johan" >actual &&
> + test_cmp expected actual
> +'
> +
> +test_expect_success 'with a bodied message that lacks a trailing newline after the body' '
> + cat >expected <<-\EOF &&
> + area: change
> +
> + details about the change.
> +
> + Reviewed-by: Peff
> + Acked-by: Johan
> + EOF
> + printf "area: change\n\ndetails about the change." |
> + git interpret-trailers --trailer "Reviewed-by: Peff" \
> + --trailer "Acked-by: Johan" >actual &&
> + test_cmp expected actual
> +'
> +
> +test_expect_success 'with a message that lacks a trailing newline after the trailers' '
> + cat >expected <<-\EOF &&
> + area: change
> +
> + Reviewed-by: Peff
> + Acked-by: Johan
> + EOF
> + printf "area: change\n\nReviewed-by: Peff" |
> + git interpret-trailers --trailer "Acked-by: Johan" >actual &&
> + test_cmp expected actual
> +'
> +
> test_expect_success 'with multiline title in the message' '
> cat >expected <<-\EOF &&
> place of
> --
> 2.45.2
next prev parent reply other threads:[~2024-09-06 16:21 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-05 17:34 [PATCH] interpret-trailers: handle message without trailing newline Brian Lyles
2024-09-05 18:24 ` Brian Lyles
2024-09-06 4:08 ` [PATCH v2] " Brian Lyles
2024-09-06 9:07 ` Phillip Wood
2024-09-06 15:23 ` Junio C Hamano
2024-09-06 14:50 ` [PATCH v3] " Brian Lyles
2024-09-06 16:21 ` Junio C Hamano [this message]
2024-09-09 9:13 ` Phillip Wood
2024-09-09 15:58 ` Junio C Hamano
2024-09-09 9:13 ` Phillip Wood
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=xmqqy144wy60.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=brianmlyles@gmail.com \
--cc=git@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.