Interesting. I could be wrong. Let me clarify what I did and what I observe. I edited the Makefile and put back the NO_REGEX = YesPlease line. Then I configured the build as ./configure —with-libpcre2=/usr/local then built and installed git. otool -L git shows git binary is dynamically linking the libpcre in /usr/local However, it looks like this third party library is also used for -G searches (plain POSIX regex or PCRE), since it accepts and correctly finds things like ‘\btext\b’. That is git log —all -p -G ‘\main\b’ works Furthermore, -G works with multibyte strings as well: git log --all -p -G '顔🏁’ What doesn’t work is multibyte strings with PCRESs, so for example this does not work: git log --all -p -G ‘\b顔🏁\b’ This doesn’t seem to be consistent with the thesis that regex library from compat is used for -G searches and that it doesn’t support multibyte strings? > On Mar 27, 2023, at 5:11 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > > Mario Grgic <mario_grgic@xxxxxxxxxxx> writes: > > [administrivia: do not top post] > >>> Mario Grgic <mario_grgic@xxxxxxxxxxx> writes: >>> ... >>>> + NO_REGEX = YesPlease >>>> PTHREAD_LIBS = >>>> endif >>> >>> It will unfortunately break multibyte support on macOS by reverting >>> what 1819ad32 (grep: fix multibyte regex handling under macOS, >>> 2022-08-26) did. > >> In my case, I compiled git with pcre2 support, using third party >> PCRE2 library: https://github.com/PCRE2Project/pcre2 and PCRE and >> multibyte support in git works with it just fine. > > Sorry, you misunderstood. 1819ad32 is about enabling multi-byte > support for normal regexp types, and does not have anything to do > with pcre. By setting NO_REGEX, the build will not link with > Apple's regex library but the one from compat/ and that version is > what is used for -G and -E (not -P). -G/-E patterns with multi-byte > would not work with compat/ stuff, but they should work when linked > with Apple's regex library. >
