How to install Git with PCRE support on OSX with homebrew?

问题

When I run

$ git grep -P "<pattern>"

I get the following error:

fatal: cannot use Perl-compatible regexes when not compiled with USE_LIBPCRE

How can I install Git with PCRE support for OSX properly?

回答1:

With homebrew, just use

brew reinstall --with-pcre2 git

It forces to build git from source instead of downloading the bottle, but ensures that the updates will be done with the pcre support.

回答2:

Homebrew ships Git with a pre-built version (bottle) by default. You need to compile Git from source to enable PCRE support:

$ brew install pcre
$ export USE_LIBPCRE=yes
$ brew reinstall --build-from-source git

Now it should work as expected.

回答3:

With GIt 2.18 (Q2 2018) , the build option has evolved:

Git can be built to use either v1 or v2 of the PCRE library, and so far, the build-time configuration USE_LIBPCRE=YesPlease instructed the build procedure to use v1, but now it means v2.

USE_LIBPCRE1 and USE_LIBPCRE2 can be used to explicitly choose which version to use, as before.

See commit e6c531b, commit a363f98, commit a91b113 (11 Mar 2018) by Ævar Arnfjörð Bjarmason (avar).
^{(Merged by Junio C Hamano -- gitster -- in commit cac5351, 09 Apr 2018)}

Makefile: make USE_LIBPCRE=YesPlease mean v2, not v1

Change the USE_LIBPCRE flag from being an alias for USE_LIBPCRE1 to being an alias for USE_LIBPCRE2.

When support for v2 was added in my 94da919 ("grep: add support for PCRE v2", 2017-06-01, Git v2.14.0-rc0) the existing USE_LIBPCRE flag was left as meaning v1, with a note that this would likely change in a future release.
That optional support for v2 first made it into Git version 2.14.0.

The PCRE v2 support has been shown to be stable, and the upstream PCRE project is highly encouraging downstream users to move to v2, so it makes sense to give packagers of Git who haven't heard the news about PCRE v2 a further nudge to move to v2.

That PCRE v2 support does improve with Git 2.24 (Q4 2019)

See commit c581e4a (18 Aug 2019) by Beat Bolli (bbolli).
Suggested-by: Johannes Schindelin (dscho).
See commit 870eea8, commit 8a59998, commit 09872f6, commit 8a35b54, commit 685668f, commit 3448923, commit 04bef50 (26 Jul 2019), commit b65abca, commit 48de2a7, commit 45d1f37, commit 2575412, commit d316af0, commit 471dac5, commit f463beb, commit b14cf11 (01 Jul 2019), and commit 4457018, commit 4e2443b (27 Jun 2019) by Ævar Arnfjörð Bjarmason (avar).
Suggested-by: Johannes Schindelin (dscho).
^{(Merged by Junio C Hamano -- gitster -- in commit a73f917, 11 Oct 2019)}

grep: use PCRE v2 for optimized fixed-string search

Bring back optimized fixed-string search for "grep", this time with PCRE v2 as an optional backend. As noted beofre, with kwset we were slower than PCRE v1 and v2 JIT with the kwset backend, so that optimization was counterproductive.

This brings back the optimization for "--fixed-strings", without changing the semantics of having a NUL-byte in patterns.
As seen in previous commits in this series we could support it now, but I'd rather just leave that edge-case aside so we don't have one behavior or the other depending what "--fixed-strings" backend we're using.
It makes the behavior harder to understand and document, and makes tests for the different backends more painful.

This does change the behavior under non-C locales when "log"'s "--encoding" option is used and the heystack/needle in the content/command-line doesn't have a matching encoding.
See the recent change in "t4210: skip more command-line encoding tests on MinGW" in this series (following this discussion). I think that's OK. We did nothing sensible before then (just compared raw bytes that had no hope of matching).
At least now the user will get some idea why their grep/log never matches in that edge case.