On 10/03/2016 12:17 PM, Junio C Hamano wrote:
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@xxxxxxx> (some comment
that extends to the next line without being indented)
Sined-off-by: Some body Else <some.body@xxxxxxx>
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".
If we define a logical trailer line as the set of physical lines until
the next trailer line...it is true that this has some precedence in that
such lines can be written (although this might not be intentional):
$ git interpret-trailers --trailer "a=foo
bar" </dev/null
a: foo
bar
This solves the "Line 1:" case above, but raises other issues:
1. Checking for existence (trailer.ifexists) is now conceptually more
difficult. For example, handling of inner whitespace in between lines
might be confusing (currently, there is only one line, and whitespace
handling is clearly described).
2. Replacement (trailer.ifexists=replace) might replace more than expected.
3. There is a corner case - the first line might not be a trailer line.
Even if interpret-trailers knew about "(cherry picked from", a user
might enter something else there. (We could just declare such blocks as
non-trailers, but if we are already loosening the definition of a
trailer, this might be something that we should allow.)
My initial thought was to think of a trailer as a block of trailer lines
possibly interspersed with other lines. This leads to interpret-trailers
placing the trailer in the wrong place if trailer.where=after, as you
describe, but this might not be a big problem if trailer.where=after is
not widely used (and it is not the default). (The other options behave
as expected.)
There are other options like checking for indentation or checking for
balanced parentheses/brackets, but I think that these would lead to
surprising behavior for the user (this would mean that whitespace or
certain characters could turn a valid trailer into an invalid one or
vice versa, or change the behavior of trailer.ifexists, especially
"replace").