Junio C Hamano wrote:
> 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 = ®s->array[i];
> if (!regexec(®->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 $1.
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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
