On Fri, Jul 26 2019, Carlo Arenas wrote: > On Fri, Jul 26, 2019 at 6:50 AM Ævar Arnfjörð Bjarmason > <avarab@xxxxxxxxx> wrote: >> >> On Fri, Jul 26 2019, Carlo Arenas wrote: >> >> > since this moves PCRE1 out of the JIT fast path, >> >> I think you're mostly replying to the wrong thread. None of the patches >> I've sent disable PCRE v1 JIT, as the performance numbers show. The JIT >> stack is resized, and for v2 some dead code removed. > > I didn't mean JIT was disabled, but that we are calling now the regular > PCRE1 function which does UTF-8 validation (unlike the one used before) > >> > introduces the regression where git grep will abort if there is binary >> > data or non UTF-8 text in the repository/log and should be IMHO hold >> > out until a fix for that can be merged. >> >> You're talking about the kwset series, not this cleanup series. > > a combination of both (as seen in pu) and that will also happen in next if > this series get merged there. > > before this cleanup series, a git compiled against PCRE1 and not using > NO_LIBPCRE1_JIT will use the jit fast path function and therefore would > have no problems with binary or non UTF-8 content in the repository, but > will regress after. I see. Yes you're right, I misread pcrejit(3) about how the "fast path API" worked (or more accurately, misremembered). Yes, this is now a new caveat. I have some patches on top of next I'm about to send that hopefully make this whole thing less of a mess.
