On Wed, Nov 25, 2015 at 12:23 PM, Duy Nguyen <pclo...@gmail.com> wrote: > On Wed, Nov 25, 2015 at 7:47 PM, Stefan Beller <sbel...@google.com> wrote: >> On Wed, Nov 25, 2015 at 10:42 AM, Lars Schneider >> <larsxschnei...@gmail.com> wrote: >>> After some investigation I figured that ~50 Submodules are the culprit. >>> Does anyone have an idea how to speed up Git on Windows while keeping 50 >>> Submodules? >>> >>> Thanks, >>> Lars >>> >>> >> >> Use the latest version of Git ;) > > Does it do parallel refresh yet? I think it would help. I only looked > at "git log --merges origin/pu" and nothing caught my eyes.
No. The hinted patch series only does a partial shell->C conversion, which is the best guess for improving git status here. I punted on parallel local operations inside "git submodule update" for now, too as when things go wrong there, you need a human to resolve the merge conflict, and as a user you only want to deal with one merge conflict at a time instead of being left there with a ton of unresolved issues (according to the git log of older patches in the submodule area). git status should require not human interaction if things go bad within submodules, so we may want to speed that up by parallelizing the submodule part. The status command gathers all information of submodules by a call to "git submodule summary" and does some slight post processing on the output. "git submodule summary" however is written completely in shell code (200 lines, so I estimate 400 lines of C). I will benchmark that later today and check if it's worth for us to rewrite that in C for our case (we plan to have lots more submodules, but we're a linux shop) -- 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
