On Sep 18, 2010, at 3:32 PM, Jens Lehmann wrote:
>> And of course the performance issue is still relevant.
>
> Hmm, I think it still the right thing to do to a full fetch of all
> submodule changes, as you can't possibly know at fetch time what you'll
> need later. But I have to admit that "git submodule update" does some
> kind of optimization, as it only fetches submodules where the commit
> recorded in the superproject has changed. But IMO this aims a bit too
> short, as it still can lead to commits missing in submodules (which are
> on branches you didn't check out and ran "git submodule update" on).
>
> The aim of these changes is to make you able to do a fetch before you go
> onto a plane and then check out every branch of the superproject without
> having a commit missing from a submodule. And even more, you should be
> able to use all new submodule commits not yet committed inside the
> superproject without being able to forget to fetch them before you leave.
>
> But maybe we can reduce this performance impact by running the submodule
> fetches in threads. Dunno yet, I'll look into that as soon as I have the
> other two patches ready.
In a situation like mine, with 17 nested submodules, you're still going to significantly increase the time for a fetch. I understand the desire to be able to run something like `git fetch` and have everything be there, but I don't agree it should be the default behavior. Perhaps it should be a flag, like `git fetch --update-submodules` (or `git fetch --recursive`). That's friendly enough to let people know about (much friendlier than `git submodule update --recursive`), but wouldn't cause any changes to the common case. And a config variable to control whether recursive is the default would not be amiss (though I would make that config variable default to false).
I should also note that fetching all submodules may be not desired in the slightest. If I use submodules to pull in specific tagged builds of another project, I really have no desire at all to regularly update the branches in that repository. Similarly, if I pull in another project that's out of my control, I have no desire to update any submodules it may have unless the project itself changes. That's certainly the case in my project. Here's the submodule layout:
.--Root-.
/ / /|\ \ \
A B C D E F G
|
H
/|\
I J K
/|\
L M N
/|\
O P Q
I control the root, and I control most of the first-level of submodules. I would also not mind seeing updates to other submodules at that level, though that doesn't generally concern me. However, I don't control submodule H, and I have absolutely no desire whatsoever to see updates to I-Q unless needed by submodule H. In this layout, regularly running `git submodule update --init --recursive` works perfectly. Having `git fetch` fetch submodules I-Q on every invocation is a complete waste of my time.
-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