Re: --progress for git submodule update?

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 14, 2012, 21:45 UTC
Message-ID: <7vd38eoo0u.fsf@alter.siamese.dyndns.org>
In-Reply-To: <4F60F4A6.1070507@web.de>

Jens Lehmann <Jens.Lehmann@web.de> writes:

Show 16 quoted lines

> 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.