Jonathan Tan <jonathanta...@google.com> writes:
> 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 <s...@body.xz> (some comment
that extends to the next line without being indented)
Sined-off-by: Some body Else <some.b...@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".
