Re: [RFC/PATCH 0/2] place cherry pick line below commit title

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 3, 2016, 19:17 UTC
Message-ID: <xmqqbmz16y42.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <e03fdabd-6690-5244-5f79-1715b0364845@google.com>

Jonathan Tan <jonathantanmy@google.com> writes:

Show 9 quoted lines

> That sounds reasonable to me. Would a patch set to implement this new
> trailer block heuristic (in both sequencer and trailer) be reasonable?
> And if yes, should trailer know about the "(cherry picked from"
> prefix? (I can see it both ways - knowing about the "(cherry picked
> from" prefix would make it consistent with sequencer, but it seems
> like a detail that it shouldn't know about. Writing
> "Cherry-picked-from:" instead probably wouldn't solve our problem
> because, for backwards compatibility, we would still need to support
> reading the old format.)

If we were to go that route, I'd suggest keeping the historical practice supported, exactly because you would need to be prepared to cherry-pick an old commit.

It may be necessary for the code to analize the lines in a block identified as "likely to be a trailing block" more carefully, though. The example 59f0aa94 in the message you are responding to has "Link 1:" that consists of 3 physical lines. An instruction to interpret-trailers to add a new one _after_ "Link-$n:" may have to treat these as a single logical line and do the addition after them, i.e. before "Link 2:" line, for example.

I also saw

	Signed-off-by: Some body <some@body.xz> (some comment
        that extends to the next line without being indented)
	Sined-off-by: Some body Else <some.body@else.xz>

where the only clue that the second line is logically a part of the first one was the balancing of parentheses (or [brakets]). To accomodate real-world use cases, you may have to take into account a lot more than the strict rfc-822 style "line folding".