Junio C Hamano wrote:

quoted text
> I personally think it was a mistake that the loop returns failure when
> there is any pattern that does not match (it is a useful feature that a
> match with a negated one forces an early return, though).
> 
> We may want to fix the semantics to be something like:
> 
> 	for (i = 0; i < regs->nr; i++) {
>         	struct ff_reg *reg = &regs->array[i];
>                 if (!regexec(&reg->re, line_buffer, 2, pmatch, 0)) {
> 			if (reg->negate) {
> 	                	free(line_buffer);
> 	                	return -1;
> 			}
>                         break;
> 		}
> 	}
>         if (regs->nr <= i) {
>         	free(line_buffer);
> 		return -1;
> 	}
> 	... use pmatch() ...
> 
> I.e. (1) negative match forces an early return (useful for catching
> language keywords), (2) first positive match is used, and (3) no match is
> a failure.
> 
> Of course, by definition the above "fix" changes the semantics, and will
> break people's existing setup if somebody has an existing custom pattern
> string that does use more than one positive regexp anded together with
> "\n", but I somehow suspect nobody sane depends on the current broken
> semantics.
> 
> It would help making JdS's ObjC alternates easier to write.  You can say:
> 
> 
> 	/* A or B */
> 	"...(A|B)$"
>         "\n" /* or C or D */
>         "...(C|D)$"
> 
> and both captures around A|B and C|D would be saved in .

Just to let you know another pair of eyes has given the above a
once over, I agree with your proposal. "or" semantics makes more sense
than "and".

-brandon
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html