Re: Bug Report: Multi-line trailers containing empty lines break parsing

From: ZheNing Hu <adlternative@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Christian Couder <christian.couder@gmail.com>,
	Taylor Blau <me@ttaylorr.com>, git <git@vger.kernel.org>,
	Matthias Buehlmann <Matthias.Buehlmann@mabulous.com>,
	Jonathan Tan <jonathantanmy@google.com>
Subject: Re: Bug Report: Multi-line trailers containing empty lines break parsing
Date: Fri, 26 Mar 2021 18:25:26 +0800	[thread overview]
Message-ID: <CAOLTT8QPJJWh_Xm=n+i7z5+5w=eBq9tcr5-yBmhovzqOXP=jnQ@mail.gmail.com> (raw)
In-Reply-To: <xmqqmturw13r.fsf@gitster.g>

Junio C Hamano <gitster@pobox.com> 于2021年3月26日周五 上午2:16写道：
>
> ZheNing Hu <adlternative@gmail.com> writes:
>
> > Christian Couder <christian.couder@gmail.com> 于2021年3月25日周四 下午3:54写道：
> >>
> >> Maybe it's not enough, but the doc already has the following:
> >>
> >> ------
> >> Existing trailers are extracted from the input message by looking for
> >> a group of one or more lines that (i) is all trailers, or (ii) contains at
> >> least one Git-generated or user-configured trailer and consists of at
> >> least 25% trailers.
> >> The group must be preceded by one or more empty (or whitespace-only) lines.
> >> The group must either be at the end of the message or be the last
> >> non-whitespace lines before a line that starts with '---' (followed by a
> >> space or the end of the line). Such three minus signs start the patch
> >> part of the message. See also `--no-divider` below.
> >>
> >> When reading trailers, there can be whitespaces after the
> >> token, the separator and the value. There can also be whitespaces
> >> inside the token and the value. The value may be split over multiple lines with
> >> each subsequent line starting with whitespace, like the "folding" in RFC 822.
> >> ------
> >
> >
> > Maybe I don't have enough right to speak on this issue, but I always think that
> >  the empty line is intentional by the designer, especially when I test it.
>
> People like you, who is relatively new to the system and the list,
> are valuable source of information for us to learn where in the
> current system and documentation we have room to improve and
> clarify.  You do have right, and we welcome your input.
>

Thanks:)

> Care to clarify what you mean by "the empty line is intentional by
> the designer"?  The designer of the current "trailer" intended to
> make the "last paragraph" (where "paragraph" is defined as a run of
> lines without an empty line in it, so that one or more continguous
> empty lines separate "paragraphs") where the trailers sit in the log
> message.  Is that what you mean?  Or something else?

Emmm, I mean generally speaking, the entire commit infomations is divided into
three paragraphs: "subject"/"message"/"trailers".

When we use `--parse` to get those trailers, normally it can indeed be obtained,
But if in the middle of the trailers have a extra empty lines or lines with only
whitespaces, All trailers before the blank line will be discarded, I think it is
acceptable.Because It seems that the previous content belongs to the message
section.

Like this:
------
(subject)

First paragraph:
hello world

Second paragraph:
what happen if some thing like

this: Use git to commit code to git

Signed-off-by: CoCo <cc@gg.com>
Deleted-by: ADL <a@gg.com>
-----

"this: Use git to commit code to git" seem like a trailer,
but it's user's message.

So I think the purpose of these blank lines is to separate the
three parts of the commit information. It is normal for the blank
lines inside trailers to cause ambiguity.

Please correct me if I what I said is wrong.
--
ZheNing Hu