From: Jonathan Tan <jonathantanmy@google.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, peff@peff.net
Subject: Re: [RFC/PATCH 3/3] mailinfo: handle in-body header continuations
Date: Fri, 16 Sep 2016 13:49:18 -0700 [thread overview]
Message-ID: <1b392241-461e-3b87-400d-70d66903e3d7@google.com> (raw)
In-Reply-To: <xmqq8turk3aw.fsf@gitster.mtv.corp.google.com>
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 in
> mi->log_message and without this function getting any chance to
> return 1, so a careful caller may want to flush in_line_header, but
> the overall result of the mailinfo subsystem in such a case would be
> an error ("you didn't have any patch or a message?"), so it may not
> matter too much.
Noted. (This was one of my concerns - that the caller should, but did
not, flush.)
> What am I missing?
>
> 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:
From: Me <me@example.com>
-- 8< -- this scissors line will be treated as part of "From"
would have its scissors line treated as a header.
The main reason why I reordered the checks (in RFC/PATCH 1/3) is to
avoid this (treating a scissors line with an initial space immediately
following an in-body header as part of a header).
(If this is not a concern then yes, I agree that the way you described
is simpler and better.)
> append to mi->in_line_header strbuf;
> return 0;
> /* otherwise we know mi->in_line_header is now complete */
> check_header(mi, mi->in_line_header, ...);
> strbuf_reset(&mi->in_line_header);
> }
>
> if (mi->header_stage && (it is a blank line))
> return 0;
>
> if (mi->use_inbody_headers && mi->header_stage &&
> (the line looks like beginning of 2822 header)) {
> strbuf_addbuf(&mi->in_line_header, line);
> return 0;
> }
> /* otherwise we are no longer looking at headers */
> mi->header_stage = 0;
>
> /* normalize the log message to UTF-8. */
> if (convert_to_utf8(mi, line, mi->charset.buf))
> return 0; /* mi->input_error already set */
>
> if (mi->use_scissors && is_scissors_line(line)) {
> int i;
>
> strbuf_setlen(&mi->log_message, 0);
> mi->header_stage = 1;
>
> /*
> * We may have already read "secondary headers"; purge
> * them to give ourselves a clean restart.
> */
> for (i = 0; header[i]; i++) {
> if (mi->s_hdr_data[i])
> strbuf_release(mi->s_hdr_data[i]);
> mi->s_hdr_data[i] = NULL;
> }
> return 0;
> }
>
> if (patchbreak(line)) {
> if (mi->message_id)
> strbuf_addf(&mi->log_message,
> "Message-Id: %s\n", mi->message_id);
> return 1;
> }
>
> strbuf_addbuf(&mi->log_message, line);
> return 0;
> }
>
>
next prev parent reply other threads:[~2016-09-16 20:49 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-02 19:58 [PATCH] sequencer: support folding in rfc2822 footer Jonathan Tan
2016-09-03 2:23 ` Junio C Hamano
2016-09-06 22:08 ` Jonathan Tan
2016-09-06 23:30 ` Jonathan Tan
2016-09-07 6:38 ` Jeff King
2016-09-16 17:37 ` [RFC/PATCH 0/3] handle multiline in-body headers Jonathan Tan
2016-09-16 18:29 ` Junio C Hamano
2016-09-16 17:37 ` [RFC/PATCH 1/3] mailinfo: refactor commit message processing Jonathan Tan
2016-09-16 19:12 ` Junio C Hamano
2016-09-16 21:46 ` Jeff King
2016-09-16 17:37 ` [RFC/PATCH 2/3] mailinfo: correct malformed test example Jonathan Tan
2016-09-16 19:19 ` Junio C Hamano
2016-09-16 22:42 ` Jonathan Tan
2016-09-16 22:55 ` Junio C Hamano
2016-09-17 0:31 ` Jonathan Tan
2016-09-17 3:48 ` Junio C Hamano
2016-09-16 17:37 ` [RFC/PATCH 3/3] mailinfo: handle in-body header continuations Jonathan Tan
2016-09-16 20:17 ` Junio C Hamano
2016-09-16 20:49 ` Jonathan Tan [this message]
2016-09-16 20:59 ` Junio C Hamano
2016-09-16 22:36 ` Jonathan Tan
2016-09-16 23:04 ` Junio C Hamano
2016-09-17 0:22 ` Jonathan Tan
2016-09-16 21:51 ` Jeff King
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1b392241-461e-3b87-400d-70d66903e3d7@google.com \
--to=jonathantanmy@google.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=peff@peff.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).