It's 'git submodule update --recursive' that is taking so long silently. The problem is mainly on the first time. There are about 10 submodules that together have taken more than 30 minutes. It's not really just the amount of data, I think there are also network traffic issues that slow things down on some systems. Chris On Sun, Mar 11, 2012 at 3:50 PM, Jens Lehmann <Jens.Lehmann@xxxxxx> wrote: > Am 10.03.2012 08:17, schrieb Chris Kees: >> Would it be reasonable to have a --progress option for 'git submodule >> update'? I'm using buildbot with a git repository containing large >> submodules, and buildbot times out on the submodule update >> occasionally because there is no output for long periods of time. >> Adjusting buildbot's timeout factor will do for me in the short run. > > As cloning a submodule talks a lot about its progress am I right > suspecting it is the checkout part that is taking so long for you? > The submodule script always uses the -q option for git checkout > (which also gets rid of the unwanted "detached HEAD" messages). So > AFAICS before a --progress option could be added to the submodule > script, git checkout would have to learn an option to show progress > but not the detached HEAD message (or to just suppress that advice). > > What times are we talking about here? -- 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