git/list[1] front-page[2] threads[3] people[4] search[5] about
 

git grep -P is multiline for negative lookahead/behind

From
MGMichael Giuffrida <michaelpg@chromium.org>
Date
Aug 1, 2016, 09:09 UTC
Message-ID
<CACi5S_0QGEgnijGyaBeZxOSobdwfA+d-wa-jrHs64Va097mnRQ@mail.gmail.com>

Negative lookahead/lookbehind with `git grep -P` considers the surrounding lines of an otherwise positive match. This differs from `grep -P` behavior. It does not repro for *positive* lookahead/lookbehind.

Example: $ echo -e 'Bar\nBar Baz\nBat' > test.txt && git add test.txt $ git grep -P 'Bar(?!\sB)' test.txt # Find 'Bar' not followed by '\sB'

With regular grep, this works:

$ grep -P 'Bar(?!\sB)' test.txt Bar

Because \s includes \n, the negative lookahead unexpectedly finds the B on line 2, and therefore line 1 fails to match the full expression.

Positive lookahead works like `grep -P`, in that it isn't unexpectedly multiline:

$ git grep -P 'Bar(?=\sB)' test.txt # Find 'Bar' followed by '\sB' test.txt:Bar Baz $ grep -P 'Bar(?=\sB)' test.txt Bar Baz

Is this expected behavior, and if so, why/where is this documented?

git: git version 2.8.0.rc3.226.g39d4020, also 2.9.2.517.gf8f7adc, both with libpcre grep: grep (GNU grep) 2.16

Next: Junio C Hamano
Message 1 of 4 in “git grep -P is multiline for negative lookahead/behind”
  1. Michael GiuffridaAug 1, 2016
  2. Junio C HamanoAug 1, 2016
  3. Michael GiuffridaAug 4, 2016
  4. Junio C HamanoAug 4, 2016

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.