On Mon, Jun 18, 2018 at 06:43:01PM -0500, Taylor Blau wrote:
> Hi,
>
> Attached is a ``fresh start'' of my series to teach 'git grep --column'.
> Since the last time I sent this, much has changed, notably the semantics
> for deciding which column is the first when given (1) extended
> expressions
René Scharfe writes:
> So let's see what your example does:
>
>$ git grep --column --not \( --not -e foo --or --not -e bar \) trace.h
>trace.h:13: * #define foo(format, ...) bar(format, __VA_ARGS__)
>$ git grep --column --not \( --not -e bar --or --not -e foo \) trace.h
>
Am 19.06.2018 um 21:11 schrieb Jeff King:
> On Tue, Jun 19, 2018 at 08:50:16PM +0200, René Scharfe wrote:
>
>> Negation causes the whole non-matching line to match, with --column
>> reporting 1 or nothing in such a case, right? Or I think doing the
>> same when the operator is applied a second
Am 19.06.2018 um 19:44 schrieb Taylor Blau:
> diff --git a/grep.c b/grep.c
> index f3329d82ed..a09935d8c5 100644
> --- a/grep.c
> +++ b/grep.c
> @@ -1257,8 +1257,8 @@ static int match_one_pattern(struct grep_pat *p, char
> *bol, char *eol,
> return hit;
> }
>
> -static int
On Tue, Jun 19, 2018 at 08:50:16PM +0200, René Scharfe wrote:
> Negation causes the whole non-matching line to match, with --column
> reporting 1 or nothing in such a case, right? Or I think doing the
> same when the operator is applied a second time is explainable.
Yes to your first question.
Am 19.06.2018 um 19:48 schrieb Jeff King:
> On Tue, Jun 19, 2018 at 07:33:39PM +0200, René Scharfe wrote:
>
>>> The key thing about this iteration is that it doesn't regress
>>> performance, because we always short-circuit where we used to. The other
>>> obvious route is to stop short-circuiting
Jeff King writes:
> Even if it's a double-inversion? The reason we carry both `col` and
> `icol` is that it allows:
>
> git grep --not --not --not --not -e a
>
> to still say "we found 'a' here". That's a dumb thing to ask for, but it
> is true in the end that we show lines with "a" (and will
On Tue, Jun 19, 2018 at 10:58:30AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > Although there are interesting cases around inversion. For example:
> >
> > git grep --not \( --not -e a --and --not -e b \)
> >
> > is equivalent to:
> >
> > git grep -e a --or -e b
> >
> > Do people
On Tue, Jun 19, 2018 at 10:58:30AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > Although there are interesting cases around inversion. For example:
> >
> > git grep --not \( --not -e a --and --not -e b \)
> >
> > is equivalent to:
> >
> > git grep -e a --or -e b
> >
> > Do people
Jeff King writes:
> Although there are interesting cases around inversion. For example:
>
> git grep --not \( --not -e a --and --not -e b \)
>
> is equivalent to:
>
> git grep -e a --or -e b
>
> Do people care if we actually hunt down the exact column where we
> _didn't_ match "b" in the
Am 19.06.2018 um 19:44 schrieb Taylor Blau:
> On Tue, Jun 19, 2018 at 07:33:39PM +0200, René Scharfe wrote:
>> Am 19.06.2018 um 18:35 schrieb Jeff King:
>>> On Mon, Jun 18, 2018 at 06:43:01PM -0500, Taylor Blau wrote:
>> We could add an optimizer pass to reduce the number of regular
>> expressions
On Tue, Jun 19, 2018 at 01:48:47PM -0400, Jeff King wrote:
> On Tue, Jun 19, 2018 at 07:33:39PM +0200, René Scharfe wrote:
> > Disabling that optimization for --column wouldn't be a regression since
> > it's a new option.. Picking a random result (based on the order of
> > evaluation) seems
On Tue, Jun 19, 2018 at 07:33:39PM +0200, René Scharfe wrote:
> > The key thing about this iteration is that it doesn't regress
> > performance, because we always short-circuit where we used to. The other
> > obvious route is to stop short-circuiting only when "--column" is in
> > effect, which
On Tue, Jun 19, 2018 at 07:33:39PM +0200, René Scharfe wrote:
> Am 19.06.2018 um 18:35 schrieb Jeff King:
> > On Mon, Jun 18, 2018 at 06:43:01PM -0500, Taylor Blau wrote:
> >> The notable case that it does _not_ cover is matching the following
> >> line:
> >>
> >>a ... b
> >>
> >> with the
Am 19.06.2018 um 18:35 schrieb Jeff King:
> On Mon, Jun 18, 2018 at 06:43:01PM -0500, Taylor Blau wrote:
>> The notable case that it does _not_ cover is matching the following
>> line:
>>
>>a ... b
>>
>> with the following expression
>>
>>git grep --column -e b --or -e a
>>
>> This will
On Tue, Jun 19, 2018 at 09:46:16AM -0700, Junio C Hamano wrote:
> Taylor Blau writes:
>
> > Attached is a ``fresh start'' of my series to teach 'git grep --column'.
> > Since the last time I sent this, much has changed, notably the semantics
> > for deciding which column is the first when given
Taylor Blau writes:
> Attached is a ``fresh start'' of my series to teach 'git grep --column'.
> Since the last time I sent this, much has changed, notably the semantics
> for deciding which column is the first when given (1) extended
> expressions and (2) --invert.
> ...
> In the future, I'd
On Mon, Jun 18, 2018 at 06:43:01PM -0500, Taylor Blau wrote:
> Attached is a ``fresh start'' of my series to teach 'git grep --column'.
> Since the last time I sent this, much has changed, notably the semantics
> for deciding which column is the first when given (1) extended
> expressions and (2)
Hi,
Attached is a ``fresh start'' of my series to teach 'git grep --column'.
Since the last time I sent this, much has changed, notably the semantics
for deciding which column is the first when given (1) extended
expressions and (2) --invert.
Both (1) and (2) are described in-depth in patch 2/7,
19 matches
Mail list logo
