Jeff King writes:
> My version seems a little clearer to me, but that is probably because I
> wrote it. If you strongly prefer the other, feel free to mark up my
> patch.
I do not have strong preference either way. Just that I thought two
loops would be shorter and easier to understand than thre
On Tue, Oct 15, 2013 at 10:52:55AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> >> Yeah, unrolling the loop is probably better. You may even be able
> >> to do so in a single pass with an extra "last > seen" pointer
> >> variable without too much additional code complexity, I would thin
Jeff King writes:
>> Yeah, unrolling the loop is probably better. You may even be able
>> to do so in a single pass with an extra "last > seen" pointer
>> variable without too much additional code complexity, I would think.
>
> I'm not sure what you mean here.
> If you mean doing a single pass
On Mon, Oct 14, 2013 at 03:45:42PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > Yeah, you are right[1]. I'm happy to re-roll. I wonder if we even need
> > to worry about a compatibility wrapper. We are already doing pointer
> > manipulations, and it is probably just as readable to roll
Jeff King writes:
> Yeah, you are right[1]. I'm happy to re-roll. I wonder if we even need
> to worry about a compatibility wrapper. We are already doing pointer
> manipulations, and it is probably just as readable to roll the loop by
> hand.
Yeah, unrolling the loop is probably better. You may
On Mon, Oct 14, 2013 at 06:31:37PM -0400, Jeff King wrote:
> > "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.
>
>
On Mon, Oct 14, 2013 at 03:25:29PM -0700, Junio C Hamano wrote:
> > + /*
> > +* 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 ">" so
Jeff King 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 bre
Split_ident currently parses left to right. Given this
input:
Your Name 123456789 -0500\n
We assume the name starts the line and runs until the first
"<". That starts the email address, which runs until the
first ">". Everything after that is assumed to be the
timestamp.
This works fine in
9 matches
Mail list logo
