Jonathan Tan [off-list ref] 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 [off-list ref] (some comment
that extends to the next line without being indented)
Sined-off-by: Some body Else [off-list ref]
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".
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 [off-list ref] (some comment
that extends to the next line without being indented)
Sined-off-by: Some body Else [off-list ref]
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").