All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "René Scharfe" <l.s.r@web.de>
Cc: Pratyush Yadav <p.yadav@ti.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	git@vger.kernel.org
Subject: Re: bug? illegal text in commit log
Date: Fri, 07 Feb 2020 13:12:37 -0800	[thread overview]
Message-ID: <xmqqh8022jay.fsf@gitster-ct.c.googlers.com> (raw)
In-Reply-To: <c67e59a2-0f81-8311-e14c-f27876e45cf0@web.de> (=?utf-8?Q?=22R?= =?utf-8?Q?en=C3=A9?= Scharfe"'s message of "Fri, 7 Feb 2020 21:31:03 +0100")

René Scharfe <l.s.r@web.de> writes:

> That's a good idea from a usability point of view.  However, mailinfo()
> parses patches line by line.  It doesn't know the total number of lines
> until it's done.  (It would if the Lines header from RFC 1036 was
> mandatory for emails; RFC 2076 says it's "not standardized for use in
> e-mail".)  It cannot easily go back at that point.
>
> Reading the whole message into a buffer or a temporary file would be an
> option, but that would give up the nice property that patches are
> streamed.

True, but we could do a two-pass approach, perhaps?  That is

 * The first pass does exactly the same as what today's code does,
   PLUS it prepares for the case where we thought the log message
   ended because we saw "diff -" or "Index: " before seeing "---",
   by scanning for the first "---"while running handle_patch().

   If there is no such "oops, a 'diff -' in the log message fooled
   us" event, we complete with what today's code does.

 * But if we detect such a case during the first pass, we run
   ourselves again with the same input and arguments, PLUS an extra,
   new option, which tells us that "we know '---' exists in the
   input and it *is* the patchbreak.  This of course can be done
   only when the standard input is seekable, but builtin/am.c does
   store the mail in a file, so...


      reply	other threads:[~2020-02-07 21:12 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-04  6:14 bug? illegal text in commit log Michael S. Tsirkin
2020-02-04 21:10 ` René Scharfe
2020-02-04 21:25   ` Junio C Hamano
2020-02-06  6:34     ` Michael S. Tsirkin
2020-02-06 16:17       ` Junio C Hamano
2020-02-06 16:45   ` Junio C Hamano
2020-02-06 17:30     ` René Scharfe
2020-02-07  5:40       ` Junio C Hamano
2020-02-07 20:30         ` René Scharfe
2020-02-12  2:24           ` Jeff King
2020-02-06 23:56     ` Michael S. Tsirkin
2020-02-07 11:02     ` Pratyush Yadav
2020-02-07 20:31       ` René Scharfe
2020-02-07 21:12         ` Junio C Hamano [this message]

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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqh8022jay.fsf@gitster-ct.c.googlers.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=l.s.r@web.de \
    --cc=mst@redhat.com \
    --cc=p.yadav@ti.com \
    /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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.