Jens Lehmann <Jens.Lehmann@xxxxxx> writes: > Am 13.03.2012 03:17, schrieb Chris Kees: >> 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. > > I suppose with "first time" you mean right after "git submodule init", > when the submodules have to be cloned initially? Thinking about that > again, you mentioned a buildbot doing all that. When the submodules > are updated from a script, no progress output is shown at all and only > the line "Cloning into 'xxx'..." will appear for each submodule, which > explains why you don't see output for quite some time. > > So I suspect increasing the timeout on your buildbot is the way to go, > as progress output is intended for humans. Considering that more often than not, people who run stuff from cronjob request us to be quiet when nothing wrong happens, I think that is a sane thing to suggest. I do not mind "submodule $subcmd --progress" to pass "--progress" down to whatever underlying git commands it uses, or squelch "-q" that it uses when running them by default, though. We may even want to make "git submodule init -q" to squelch the "Cloning into..." message, but that is a separate topic. -- 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