Re: sb/submodule-parallel-fetch,

From: Stefan Beller <sbeller@google.com>
Date: Dec 14, 2015, 19:37 UTC
Message-ID: <CAGZ79kaD5vtrofHmeWyKEDiNMSuuCfwwHHie8O03PdjQRK_V=A@mail.gmail.com>
In-Reply-To: <xmqqvb84d1p1.fsf@gitster.mtv.corp.google.com>

On Fri, Dec 11, 2015 at 3:07 PM, Junio C Hamano <gitster@pobox.com> wrote:

Show 14 quoted lines

> Stefan Beller <sbeller@google.com> writes:
>
>> On Fri, Dec 11, 2015 at 1:37 PM, Johannes Sixt <j6t@kdbg.org> wrote:
>>>
>>> Generally, I'm already quite satisfied with the state of the
>>> infrastructure at the tip of the branch.
>>
>> I was about the rework the patch series.
>
> OK.
>
> I think the very early part of the series, up to 8fc3f2ee (sigchain:
> add command to pop all common signals, 2015-09-30), may be fine
> as-is (i.e. just rebase on top of updated 'master').

I did that.

Show 6 quoted lines

>
> The step after that, i.e. asynch processor, is the most interesting
> and important one.  Since it was written, I think the improvements
> that we want to be rolled into it from the beginning are:
>
>  - do not rely on waitpid(-1);

and documented in the commit message why we abandoned that implementation.

>
>  - no need for set_nonglocking(), squashing a4433fd4a and
>    6f963a895a9 in;

6f963a895a9 (strbuf: update documentation for strbuf_read_once()) squashed into a commit before your anticipated "very early part which may be fine as is", but no worries.

>  - correct the early-shutdown bug 79f38577 and again in 63ce47e1;
>
>  - child_process_clear() in 1c53754a, which probably will become
>    unnecessary if the series is rebuilt on top of updated 'master';

it did.

Show 6 quoted lines

>
>  - follow-up fixes and enhancements to the tests in c3a5d11 and
>    74cc04d;
>
>  - debugging support in 7eb93e91069 (from the other series that
>    builds on top).

not just cherry picking that one, but also adapt the tests in this series to use it.

>
> That would slim down not just the total number of patches, but also
> the amount of the code that needs to be looked at (as we would not
> add code only to later remove or fixup).