On 09/16/2016 04:04 PM, Junio C Hamano wrote:
Jonathan Tan writes:
I'm concerned about what happens if check_header fails - we would then
have some lines which need to be treated as log messages. (At least,
they are currently treated that way.)
I actually think we
Jonathan Tan writes:
> On 09/16/2016 01:59 PM, Junio C Hamano wrote:
>> if (mi->in_line_header->len) {
>> /* we have read the beginning of one in-line header */
>> if (line->len && isspace(*line->buf) &&
>>
On 09/16/2016 01:59 PM, Junio C Hamano wrote:
if (mi->in_line_header->len) {
/* we have read the beginning of one in-line header */
if (line->len && isspace(*line->buf) &&
!(mi->use_scissors && is_scissors_line(line))) {
Minor note:
On Fri, Sep 16, 2016 at 10:37:24AM -0700, Jonathan Tan wrote:
> Mailinfo currently handles multi-line headers, but it does not handle
> multi-line in-body headers. Teach it to handle such headers, for
> example, for this input:
>
> Subject: a very long
>broken line
>
> Subject: another
Jonathan Tan writes:
>> handle_commit_msg(...)
>> {
>> if (mi->in_line_header->len) {
>> /* we have read the beginning of one in-line header */
>> if (line->len && isspace(*line->buf))
>
> This would mean that a message like the following:
On 09/16/2016 01:17 PM, Junio C Hamano wrote:
In other words, wouldn't something like the illustration at the end
of this message sufficient? If the body consists solely of in-body
header without any patch or patchbreak, we may reach EOF with
something in mi->in_line_header buffer and nothing
Jonathan Tan writes:
> Instead of repeatedly calling "check_header" (as in this patch), one
> alternate method to accomplish this would be to have a buffer of
> potential header text in struct mailinfo to be flushed whenever a header
> is known to end (for example, if
7 matches
Mail list logo