> I didn't say this in the previous round because it smelled like an
> RFC, but for a real submission, 2/2 may be doing too many things at
> once. I suspect this is more or less "taste" thing, so I won't mind
> too much as long as the reviewers are OK with it.
The patch 2/2 is now broken up into the first five patches.
There are only 2 minor changes:
* If a number of tasks <= 0 is specified, use the number of cpus instead.
* Renamed the command line option in test-run-command.c to
"run-command-parallel-4"
as the 4 is hardcoded there.
The patch 6,7 are small cleanups (6 should add a test in a reroll)
Patches 7,8,9 are a preview of how I want to proceed in the near future:
After these functions are split out, we can add another patch on top which
rewrites the short main loop in cmd_update to be in C in submodule--helper
running in parallel.
It took me a while to get the idea how to realize parallelism with the
parallel run command structure now as opposed to the thread pool I proposed
earlier, but I think it will be straightforward from here.
Stefan
Stefan Beller (10):
strbuf: Add strbuf_read_noblock
run-command: factor out return value computation
run-command: add an asynchronous parallel child processor
fetch_populated_submodules: use new parallel job processing
submodules: Allow parallel fetching, add tests and documentation
git submodule update: Redirect any output to stderr
git submodule update: pass --prefix only with a non empty prefix
git submodule update: cmd_update_recursive
git submodule update: cmd_update_recursive
git submodule update: cmd_update_fetch
Documentation/fetch-options.txt | 7 +
builtin/fetch.c | 6 +-
builtin/pull.c | 6 +
git-submodule.sh| 242 ++
run-command.c | 281
run-command.h | 36 +
strbuf.c| 25 +++-
strbuf.h| 6 +
submodule.c | 119 -
submodule.h | 2 +-
t/t0061-run-command.sh | 20 +++
t/t5526-fetch-submodules.sh | 19 +++
test-run-command.c | 24
13 files changed, 620 insertions(+), 173 deletions(-)
--
2.6.0.rc0.131.gf624c3d
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
