From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] split_ident: parse timestamp from end of line
Date: Mon, 14 Oct 2013 15:25:29 -0700 [thread overview]
Message-ID: <xmqqwqlfebhi.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <20131014202734.GA7007@sigill.intra.peff.net> (Jeff King's message of "Mon, 14 Oct 2013 16:27:34 -0400")
Jeff King <peff@peff.net> writes:
> You could take this concept further and try to do something clever with
> the email when we notice the extra ">". But I think that is where this
> crosses from "easily and simply covers a class of errors" into "losing
> proposition trying to tweak heuristics around various breakages".
True.
> The only thing that gives me pause here is that parsing from the right
> would close the door to ever adding any new information on the end of an
> ident line. I'd be surprised if that door wasn't already closed by the
> existing parsers, but I feel like the topic might have come up sometime
> in the past year or two (but I can't seem to find anything in the
> archive).
I do not recall any, either.
The approach to parse from the right-end feels like the simplest and
the clearest one to get the piece of information that matters in the
presence of breakages like the ones you mentioned.
> + /*
> + * Look from the end-of-line to find the trailing ">" of the mail
> + * address, even though we should already know it as split->mail_end.
> + * This can help in cases of broken idents with an extra ">" somewhere
> + * in the email address. Note that we are assuming the timestamp will
> + * never have a ">" in it.
> + *
> + * Note also that this memchr can never return NULL, as we would
> + * always find at least the split->mail_end closing bracket.
> + */
> + cp = memrchr(split->mail_end, '>', len - (split->mail_end - line));
> + for (cp = cp + 1; cp < line + len && isspace(*cp); cp++)
> ;
"git grep" tells me this is the first use of memrchr(), which,
unlike memchr(), is _GNU_SOURCE-only if I am not mistaken, so we may
need a fallback definition in the compat/ and NEEDS_MEMRCHR in the
Makefile, I think.
next prev parent reply other threads:[~2013-10-14 22:25 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-14 20:27 [PATCH] split_ident: parse timestamp from end of line Jeff King
2013-10-14 22:25 ` Junio C Hamano [this message]
2013-10-14 22:31 ` Jeff King
2013-10-14 22:45 ` Jeff King
2013-10-14 22:45 ` Junio C Hamano
2013-10-14 23:29 ` Jeff King
2013-10-15 17:52 ` Junio C Hamano
2013-10-15 18:03 ` Jeff King
2013-10-15 18:48 ` Junio C Hamano
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=xmqqwqlfebhi.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--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.
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.