Re: [RFC PATCH 0/2] Teach fetch and pull to recursively fetch submodules too

From: Kevin Ballard <kevin@sb.org>
Date: Sep 15, 2010, 00:18 UTC
Message-ID: <778BC76C-FDFA-4EF0-AA94-6631272DEC02@sb.org>
In-Reply-To: <7vocckhcb6.fsf@alter.siamese.dyndns.org>

On Aug 29, 2010, at 10:58 PM, Junio C Hamano wrote:

Show 14 quoted lines

> Jens Lehmann <Jens.Lehmann@web.de> writes:
> 
>> So I extended the fetch command to fetch populated submodules too. I
>> also added a command line option to fetch and pull and the second patch
>> introduces a per submodule config option to give users the chance to
>> control that behavior.
>> 
>> And maybe we need a config option to customize that behavior
>> for all submodules or all repos too?
>> 
>> Opinions?
> 
> I think your "if a particular submodule is already initialized, recursing
> into it is more likely than not what the user wants" is a sound heuristic.

This was just merged onto the next branch a few days ago, so I finally got a chance to test it out, and it's not pretty. The project I'm working in has a bunch of submodules, and this makes a simple `git fetch` take about 20 seconds. Even worse, it makes `git remote update` take significantly longer, as it apparently fetches all submodules twice. As a comparison, with all the submodule fetching turned off, a normal `git fetch` takes about 1.5 seconds. Oddly enough, it doesn't seem to be fetching submodules recursively - one of my submodules has a whole tree of about 6 different submodules, but those embedded submodules aren't being fetched.

There seems to be 3 issues here. The first is `git remote update`, which I am fond of using, causes buggy behavior where it fetches all submodules twice. The second is this submodule fetch doesn't appear to be recursive. The third issue is `git fetch` doesn't have any business fetching submodules when the submodule reference was never changed as part of the fetch, especially if the main fetch itself didn't even find any changes. It seems to me that the correct behavior would be to look at all the fetched commits to see if any of them change the submodule reference, and only in that case should it automatically fetch any submodules whose references were modified. The stated desire of avoiding "(commits not present)" when doing a diff will still be met, but it will avoid slowing down the nor
 mal case of a `git fetch`.

It also seems like there ought to be a config variable one can set for the default behavior if submodule.<name>.fetch is not present in .gitmodules or in .git/config.

-Kevin Ballard