git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: --progress for git submodule update?

From
Jens Lehmann <jens.lehmann@web.de>
Date
Mar 14, 2012, 19:42 UTC
Message-ID
<4F60F4A6.1070507@web.de>
In-Reply-To
<CAOVFbFhMfpFa5=a0Z50H7nHdQFHn9Y4ApUnQJq6GCOFP+AKy5A@mail.gmail.com>
Am 13.03.2012 03:17, schrieb Chris Kees:
Show 5 quoted lines
> 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.

Previous: Chris KeesNext: Junio C Hamano
Message 4 of 7 in “--progress for git submodule update?”
  1. Chris KeesMar 10, 2012
  2. Jens LehmannMar 11, 2012
  3. Chris KeesMar 13, 2012
  4. Jens LehmannMar 14, 2012
  5. Junio C HamanoMar 14, 2012
  6. Chris KeesMar 15, 2012
  7. Jens LehmannMar 15, 2012

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.