git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [RFC/PATCH 3/3] mailinfo: handle in-body header continuations

From
Junio C Hamano <gitster@pobox.com>
Date
Sep 16, 2016, 23:04 UTC
Message-ID
<xmqq7fabigzf.fsf@gitster.mtv.corp.google.com>
In-Reply-To
<128036e3-47b4-b7ae-034f-8d227a62729f@google.com>
Jonathan Tan <jonathantanmy@google.com> writes:
Show 8 quoted lines
> 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: this means that the scissors check appears twice in the
> code, once here and once below (for the non-header case).

Yes. I actually was wondering if it is even more sensible to always have the scissors check at the very beginning. Even if we saw a half-written in-body header already in the message, when we see a scissors line, we clear the slate and restart as if the line after the scissors is the first line in the body of the message.

Show 11 quoted lines
>>                         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, ...);
>
> (Sorry - should have also noticed this in your original e-mail.)
>
> 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 should refactor check_header() further so that in-body header processing does not even see things that shouldn't be changed. The current check_header() should be used only for real mail headers, and then a reduced version of check_header() that is called for in-body will _ONLY_ handle the header lines that are handled by the first "search for the interesting parts" loop.

And of course we would update your "does it look like rfc2822?" to match what are handled by the "interesting parts" loop. That I think would match the current behaviour much better, I would think.

The ">From " and "[PATCH]" cases in check_header() should not even be there. We should handle them inside handle_commit_msg(), as these two cases should never appear in the real header part of a message.

And if we clean it up like that, I do not think we would ever need to worry about "ah, it looked like a header but it is not after all". And not having to worry about it is a good thing and should be one of the primary goals in this conversion, I whould think.

Thanks.
Previous: Jonathan TanNext: Jonathan Tan
Message 21 of 24 in “sequencer: support folding in rfc2822 footer”
  1. sequencer: support folding in rfc2822 footerJonathan Tan, Sep 2, 2016
  2. Junio C HamanoSep 3, 2016
  3. Jonathan TanSep 6, 2016
  4. Jonathan TanSep 6, 2016
  5. Jeff KingSep 7, 2016
  6. 0/3 handle multiline in-body headersJonathan Tan, Sep 16, 2016
  7. 1/3 mailinfo: refactor commit message processingJonathan Tan, Sep 16, 2016
  8. Junio C HamanoSep 16, 2016
  9. Jeff KingSep 16, 2016
  10. 2/3 mailinfo: correct malformed test exampleJonathan Tan, Sep 16, 2016
  11. Junio C HamanoSep 16, 2016
  12. Jonathan TanSep 16, 2016
  13. Junio C HamanoSep 16, 2016
  14. Jonathan TanSep 17, 2016
  15. Junio C HamanoSep 17, 2016
  16. 3/3 mailinfo: handle in-body header continuationsJonathan Tan, Sep 16, 2016
  17. Junio C HamanoSep 16, 2016
  18. Jonathan TanSep 16, 2016
  19. Junio C HamanoSep 16, 2016
  20. Jonathan TanSep 16, 2016
  21. Junio C HamanoSep 16, 2016
  22. Jonathan TanSep 17, 2016
  23. Jeff KingSep 16, 2016
  24. Junio C HamanoSep 16, 2016

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.