Re: [PATCH 0/7] grep.c: teach --column to 'git-grep(1)'
- From
Jeff King <peff@peff.net>
- Date
- Jun 19, 2018, 18:05 UTC
- Message-ID
- <20180619180525.GA28203@sigill.intra.peff.net>
- In-Reply-To
- <xmqqo9g6vet5.fsf@gitster-ct.c.googlers.com>
On Tue, Jun 19, 2018 at 10:58:30AM -0700, Junio C Hamano wrote:
Show 20 quoted lines
> Jeff King <peff@peff.net> 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 first case? The two are equivalent, but I > > have to wonder if somebody writing the first one really cares. > > I may be misunderstanding the question, but I personally would feel > that "git grep --not <ANYTHING>" is OK to say "the entire line is at > fault that it did not satisify the criteria to match <ANYTHING>". > I.e., I'd be happy if --column marked the first column as the > beginning of the match, or --color painted the entire line in the > output of the former.
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 colorize them as such).
-Peff