Re: [PATCH] git-grep: --and to combine patterns with and instead of or

From: Junio C Hamano <junkio@cox.net>
Date: Jun 30, 2006, 17:18 UTC
Message-ID: <7vpsgqimu7.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <E1FwMPf-0005XA-N9@moooo.ath.cx>

Matthias Lederhofer <matled@gmx.net> writes:

> 1. Should the context of near be the same as -[ABC] or perhaps
>    --near=N / --near=N:M (default could be the same as specified by
>    -[ABC]).

As an end-user, I do not care either way.

> 2. Should it be possible to specify another boolean expression after
>    --near? e.g. --near ( -e foo --or ( -e bar --and -e baz )) to match
>    if the context contains foo or 'bar and baz'.

I would say why not.

> 3. Is --near just another subexpression? e.g. search for foo with
>    either A or B in the context:
>    -e foo --and ( --near A --or --near B )
>    This does not make sense without 1 and 2.

Ah, interesting. I was thinking --near to be weaker form of --and, but you made it to be a unary predicate (like --not). That would be neater.

Show 6 quoted lines

> With some or all of those features quite mighty and complex
> expressions can be build:
> -e A --and --near=3:-1 ( -e B --and --near=0:0 ( -e foo --and -e bar ) )
> This could mean: find lines containing A and have B in any of the 3
> lines before A (without the line containing A). Additionally foo and
> bar have to be found on the same line before A.

Having said that, I suspect the above made-up example may not be so useful in practice. I think a more realistic usage is "I want to find lines that contain `made-up' and `realistic' but the paragraph might have been filled by the editor and they may be found on separate nearby lines. Instead of saying `-e made-up --and -e realistic', I would say `-e made-up --near -e realistic' to find what I want". That would find the first two lines of this paragraph, among others.

> With the new extended expressions it would be really nice if git-grep
> could also be used outside a git repository :)

I am not sure about `outside' but it might be useful to extend the working tree walker and glob filter used there to match what ls-files uses so that it can do untracked files as well.