On Thu, Sep 15, 2016 at 07:15:33AM +0200, Kevin Daudt wrote:
> > > Another small thing I am not sure about is if the \ quoting can hide
> > > an embedded newline in the author name. Would we end up turning
> > >
> > > From: "Jeff \
> > > King"
> > >
> > > or somesuch into
> > >
On Wed, Sep 14, 2016 at 12:38:20PM -0700, Jeff King wrote:
> On Wed, Sep 14, 2016 at 12:30:06PM -0700, Junio C Hamano wrote:
>
> > Another small thing I am not sure about is if the \ quoting can hide
> > an embedded newline in the author name. Would we end up turning
> >
> > From: "Jeff \
>
On Wed, Sep 14, 2016 at 12:30:06PM -0700, Junio C Hamano wrote:
> Another small thing I am not sure about is if the \ quoting can hide
> an embedded newline in the author name. Would we end up turning
>
> From: "Jeff \
> King"
>
> or somesuch into
>
> Author: Jeff
>
Jeff King writes:
> On Wed, Sep 14, 2016 at 10:43:18AM -0700, Junio C Hamano wrote:
>
>> I think we can go either way and it does not matter all that much if
>> "mailinfo" changes its output or the reader of "mailinfo" output
>> changes its input--we will either be munging data read from "From:"
On Wed, Sep 14, 2016 at 10:43:18AM -0700, Junio C Hamano wrote:
> I think we can go either way and it does not matter all that much if
> "mailinfo" changes its output or the reader of "mailinfo" output
> changes its input--we will either be munging data read from "From:"
> when producing the "Auth
Kevin Daudt writes:
> When applied the the author of this patch shows up as:
>
> Author: A U Thor" (test)
>
> So I agree with Jeff[1] where he states that the surrounding quotes
> should be removed, if that's not a problem for git.
>
> [1]:https://public-inbox.org/git/20160914051305.vphknpsi
On Tue, Sep 13, 2016 at 10:54:47PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > It has been a while since I looked at rfc2822, but aren't the quoting
> > and syntax rules different for addresses versus other headers? We would
> > not want to dequote a Subject header, I think.
>
> You'r
Jeff King writes:
> It has been a while since I looked at rfc2822, but aren't the quoting
> and syntax rules different for addresses versus other headers? We would
> not want to dequote a Subject header, I think.
You're absolutely right. RFC2822 does not quite _want_ to dequote
anything. As yo
On Wed, Sep 14, 2016 at 01:46:12AM +0200, Kevin Daudt wrote:
> diff --git a/t/t5100/quoted-pair.expect b/t/t5100/quoted-pair.expect
> new file mode 100644
> index 000..9fe72e9
> --- /dev/null
> +++ b/t/t5100/quoted-pair.expect
> @@ -0,0 +1,5 @@
> +Author: "Author "The Author" Name"
> +Email: s
On Tue, Sep 13, 2016 at 05:04:45PM -0700, Junio C Hamano wrote:
> > @@ -461,6 +506,7 @@ static int check_header(struct mailinfo *mi,
> > */
> > strbuf_add(&sb, line->buf + len + 2, line->len - len -
> > 2);
> > decode_header(mi, &sb);
>
On Tue, Sep 13, 2016 at 05:04:45PM -0700, Junio C Hamano wrote:
> Kevin Daudt writes:
>
>
> It often is easier to read if smaller of the two are in the if part
> and the larger in else part. Also your switch/case is indented one
> level too deep. I.e.
>
Thanks, I've switched the order and fi
Kevin Daudt writes:
> +static int unescape_quoted_pair(struct mailinfo *mi, struct strbuf *line)
> +{
> + struct strbuf outbuf = STRBUF_INIT;
> + const char *in = line->buf;
> + int c, skip=0;
> + char escape_context=0;
Have SP around '=', i.e.
int c, skip = 0;
c
rfc2822 has provisions for quoted strings in structured header fields,
but also allows for escaping these with so-called quoted-pairs.
git currently does not do anything with this at all, and verbatim takes
over the field body.
Make sure to properly dequote these quoted-strings and comments.
Sig
13 matches
Mail list logo
