Re: What's cooking in git.git (May 2017, #01; Mon, 1)

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: May 2, 2017, 08:23 UTC
Message-ID: <CACBZZX5N0L_M9b4RTRLSvcA2u69H=s=S-VEc-Nr71wW6Scyjvw@mail.gmail.com>
In-Reply-To: <xmqqa86wgo33.fsf@gitster.mtv.corp.google.com>

On Tue, May 2, 2017 at 1:21 AM, Junio C Hamano <gitster@pobox.com> wrote:

Show 37 quoted lines

> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
>
>>> * ab/grep-pcre-v2 (2017-04-25) 20 commits
>>>  - SQUASH???
>>>  - Makefile & configure: make PCRE v2 the default PCRE implementation
>>>  - grep: remove support for concurrent use of both PCRE v1 & v2
>>>  - grep: add support for PCRE v2
>>>  - grep: add support for the PCRE v1 JIT API
>>>  - perf: add a performance comparison test of grep -E and -P
>>>  - grep: change the internal PCRE code & header names to be PCRE1
>>>  - grep: change the internal PCRE macro names to be PCRE1
>>>  - test-lib: rename the LIBPCRE prerequisite to PCRE
>>>  - grep: make grep.patternType=[pcre|pcre1] a synonym for "perl"
>>>  - grep & rev-list doc: stop promising libpcre for --perl-regexp
>>>  - log: add -P as a synonym for --perl-regexp
>>>  - log: add exhaustive tests for pattern style options & config
>>>  - grep: add a test for backreferences in PCRE patterns
>>>  - Makefile & configure: reword outdated comment about PCRE
>>>  - grep: remove redundant `regflags &= ~REG_EXTENDED` assignments
>>>  - grep: remove redundant regflags assignment under PCRE
>>>  - grep: submodule-related case statements should die if new fields are added
>>>  - grep: add tests for grep pattern types being passed to submodules
>>>  - grep: amend submodule recursion test in preparation for rx engine testing
>>>
>>>  PCRE2, which has an API different from and incompatible with PCRE,
>>>  can now be chosen to support "grep -P -e '<pattern>'" and friends.
>>
>> That squash looks good to me.
>
> Thanks.
>
> That is not a particulary helpful comment, by the way.  I can help
> topics by contributors by queuing emergency fix at the tip to make
> ones that do not build correctly buildable and testable (which is
> what the "SQUASH???" commits are about), but I'd rather not see me
> forced to find among 19 commits which one is broken and needs the
> hotfix squashed in myself.

I'm happy to change what I'm doing to be more helpful, but it's not clear to me from this & the context what that would be.

* I sent a v4 that had this bug in <20170425210548.24612-6-avarab@gmail.com>
* You pointed out that initialization bug in response
* I sent a v5 of just that patch (not the rest of the series) in
response to that in <20170426074856.29903-1-avarab@gmail.com>
* You replied in <xmqq1sser7ty.fsf@gitster.mtv.corp.google.com> in a
reply I (probably mis-)read as "no worries, I'll just squash the fix
in"

So now a ~week later in WCIG you've taken the series but added that squash instead of using my v5 of that one patch, that looks good to me (i.e. your hotfix does the same thing as my v5) but you don't think that's a helpful comment.

So what would you like to have happen instead? If it's easier I could just re-sent a v6 of the whole thing and we could do away with this squash/replace-one-patch dance.

Show 24 quoted lines

>>> * ab/grep-threading-cleanup (2017-04-16) 8 commits
>>>  - grep: given --threads with NO_PTHREADS=YesPlease, warn
>>>  - pack-objects: fix buggy warning about threads under NO_PTHREADS=YesPlease
>>>  - pack-object & index-pack: add test for --threads warning under NO_PTHREADS
>>>  - tests: add a PTHREADS prerequisite
>>>  - grep: skip pthreads overhead when using one thread
>>>  - grep: don't redundantly compile throwaway patterns under threading
>>>  - grep: add tests for --threads=N and grep.threads
>>>  - grep: assert that threading is enabled when calling grep_{lock,unlock}
>>>
>>>  Code cleanup.
>>>
>>>  Needs review.
>>
>> Between these two series there's 27 patches, and I understand it's a
>> bit of a PITA to review/get comments on it.
>>
>> Anything I should be doing differently here other than just waiting
>> for 2.13 to come out so they can be cooked further & merged down to
>> next & then master if there's no objections?
>
> There are topics that need fresh eyes to be reviewed by other
> contributors, so perhaps you can help unblock them by reviewing,
> while they pick lints from yours?

*nod*