On 9 Mar 2012, Timothy Pearson told this:
> 99% of the time is spent waiting for GIT to return from these commands:
> 'git pull'
> 'git reset --hard HEAD'
> 'git commit -a'
>
> That last one especially eats up a lot of resources, but I have found no
> other way to commit changes to a submodule reference to the parent tree.

That's gonna be slow if the cache is cold, yes: it has to stat every
file in the working tree to find out which ones are new. (It uses (the
same code as) 'git update-index --refresh', which see.)

The solution for efficient operation is always to avoid 'git commit -a',
which is really a convenience trick for quick updates. Use 'git add'
instead whenever you know, or can efficiently compute, which things have
changed. That works on submodules too: if you have a submodule named
'foo' under the current directory, and you committed a change in it,
'git add foo' stages the submodule update for commit just as if it were
a normal file.

Now if you know that all that you've done is updated submodules, you can
iterate over all submodules and check-and-add them a hell of a lot
faster than you can stat every file in the repository. At first sight
'git submodule foreach' is the right thing to use, but this is actually
wrong because it cd's into each submodule directory, which is just what
you want if you want to operate on each submodule, but just what you
don't want if you want to update the *superproject*.

Instead, try

git add $(git submodule status | grep '^+' | cut -d\  -f2)

from the top level, which should avoid statting anything unnecessarily.

-- 
NULL && (void)