On Fri, Aug 7, 2015 at 2:32 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Stefan Beller <sbeller@xxxxxxxxxx> writes: > >> On Fri, Aug 7, 2015 at 2:14 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: >>> Stefan Beller <sbeller@xxxxxxxxxx> writes: >>>> ... >>>> We can drop that hunk as it only uses the new method >>>> `submodule_name_for_path` but doesn't change functionality. >>>> So if you want to keep Heikos work, I'll just resend the patch >>>> without that hunk. >>> >>> Does such a result even make sense? Note that I wasn't talking >>> about textual conflict. >>> >>> If we followed what you just said, that patch will try to directly >>> read the data in config_name_for_path string list, which is removed >>> by Heiko's series, if I am reading it right. > > By the way, the above is more important part of the message you are > responding to. The result does not simply link, because your > unsorted_string_list_lookup() will no longer have the string list in > the first place X-<. I looked through Heikos series and think it is an improvement. I mean I can redo my patches on top of his. Specially this patch will be easy, as patch 2/4 (extract functions for submodule config set and lookup) implements get_name_for_path. All I would need to do then is expose it to the shell via the helper. > >>>> 2) Come up with a good thread pool abstraction >>>> (Started as "[RFC/PATCH 0/4] parallel fetch for submodules" ) >>>> This abstraction (if done right) will allow us to use it in different places >>>> easily. I started it as part of "git fetch --recurse-submodules" because >>>> it is submodule related and reasonably sized >>> >>> I personally think this gives the most bang-for-buck. Write that >>> and expose it as "git submodule for-each-parallel", which takes the >>> shell scriptlet that currently is the loop body of "while read mode >>> sha1 stage sm_path" in update and clone. You will have immediate >>> and large payback. >> >> You said that before. I feel like this is a bit to narrow. > > That depends on how good a design you make for the internal > "parallel execution" engine. If it is made to take an arbitrary C > function with list of arguments to call it with, for-each-parallel > would be just a degenerate and narrow case where that arbitrary C > function happens to be exec'ing a shell and feed a shell scriptlet > to it. > > The internal parallel execution engine would be reusable without any > change to call C native functions, allowing you to do everything > inside the process in the future. And the "narrow" case is a good > first step to validate your design actually _works_. > -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html