[RFC PATCHv1 00/12] git submodule update in C with parallel cloning

So eventually we want to have projects with lots of submodules such as Android (which would have O(1000) submodules).

The very first thing a user does is cloning a project, so we want to impress with speed there as well. git clone however is lazy and just calls `git submodule update --init --recursive`. So we need to make that fast.

This series rewrites parts of git submodule update in C and in the second-last patch it separates cloning and doing the other actions(checkout/rebase/merge etc) by doing the cloning first and then the rest.

The last patch (which is broken in the first version of the series), then proceeds to put the cloning of the submodules into the get_next_task callback of the parallel process API.

That said, the first few patches introduce some churn in the behavior and tests of Git, so maybe put your eyes there?

Thanks for any advice, Stefan

Stefan Beller (12):
  git submodule update: Announce skipping submodules on stderr
  git submodule update: Announce uninitialized modules on stderr
  git submodule update: Move branch calculation to where it's needed
  git submodule update: Announce outcome of submodule operation to
    stderr
  git submodule update: Use its own list implementation.
  git submodule update: Handle unmerged submodules in C
  submodule config: keep update strategy around
  git submodule update: check for "none" in C
  git submodule update: Check url in C
  git submodule update: Clone projects from within C
  submodule--helper: Do not emit submodules to process directly.
  WIP/broken Clone all outstanding submodules in parallel

 builtin/submodule--helper.c | 221 ++++++++++++++++++++++++++++++++++++++++++++
 git-submodule.sh            |  38 +++-----
 submodule-config.c          |  11 +++
 submodule-config.h          |   1 +
 t/t7400-submodule-basic.sh  |  12 +--
 t/t7406-submodule-update.sh |  12 +--
 6 files changed, 256 insertions(+), 39 deletions(-)