Re: [PATCHv3 00/11] Expose the submodule parallelism to the user

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 4, 2015, 17:54 UTC
Message-ID: <xmqqk2pxbqft.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <1446597434-1740-1-git-send-email-sbeller@google.com>

Stefan Beller <sbeller@google.com> writes:

Show 13 quoted lines

> Where does it apply?
> ---
> This series applies on top of d075d2604c0f92045caa8d5bb6ab86cf4921a4ae (Merge
> branch 'rs/daemon-plug-child-leak' into sb/submodule-parallel-update) and replaces
> the previous patches in sb/submodule-parallel-update
>
> What does it do?
> ---
> This series should finish the on going efforts of parallelizing
> submodule network traffic. The patches contain tests for clone,
> fetch and submodule update to use the actual parallelism both via
> command line as well as a configured option. I decided to go with
> "submodule.jobs" for all three for now.

The order of patches and where the series builds makes me suspect that I have been expecting too much from the "parallel-fetch" topic.

I've been hoping that it would be useful for the project as a whole to polish the other topic and make it available to wider audience sooner by itself (both from "end users get improved Git early" aspect and from "the core machinery to be reused in follow-up improvements are made closer to perfection sooner" perspective). So I've been expecting that "Let's fix it on Windows" change directly on top of sb/submodule-parallel-fetch to make that topic usable before everything else. Other patches in this series may require the child_process_cleanup() change, so they may be applied on top of the merge between sb/submodule-parallel-fetch (updated for Windows) and rs/daemon-plug-child-leak topic.

That does not seem to be what's happening here (note: I am not complaining; I am just trying to make sure expectation matches reality). Am I reading you correctly?

I think sb/submodule-parallel-fetch + sb/submodule-parallel-update as a single topic would need more time to mature to be in a tagged release than we have in the remainder of this cycle. It is likely that the former topic has a chance to get rebased after 2.7 happens. And that would allow us to (1) use the child_process_cleanup() from get-go instead of _deinit and to (2) get the machinery right both for UNIX and Windows from get-go. Which would make the result easier to understand. As this is one of the more important areas, it matters to keep the resulting code and the rationale behind it understandable by reading "log --reverse -p".

Thanks.