To those CC'd on the original message, sorry for the repeat send to the list but the original was rejected due to not being text/plain. On Sep 14, 2010, at 5:18 PM, Kevin Ballard wrote: > On Aug 29, 2010, at 10:58 PM, Junio C Hamano wrote: > >> Jens Lehmann <Jens.Lehmann@xxxxxx> 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 normal 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. Turns out the recursive fetch behavior is a bit more subtle than I thought. It actually recurses one level deep into submodules, but no further. I have a submodule foo, which has a submodule bar, which has a submodule baz, and when I run `git fetch` I get Fetching submodule foo Fetching submodule bar There's two problems here. The first is it doesn't tell me that bar is actually foo/bar, and the second is it never fetches baz. -Kevin Ballard-- 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