On Oct 13, 2010, at 2:27 PM, Marc Branchaud wrote: >> I'm not sure it's correct though. For example, with my scenario every >> single submodule is required for a correct build, but most submodules >> should definitely not be updated unless their parent submodule updates its >> gitlink. So --recursive is recommended for `git clone`, but a >> non-recursive fetch would be the correct behavior going forward. > > What about a "smart" recursive fetch? One where if *any* new ref in the > superproject changes the superproject's submodule ref, *and* that submodule > ref isn't already in the submodule repo, then fetch updates the submodule. > Recurse as needed. > > That way I don't think there'd be any missing commits when checking out > different branches in the superproject, and submodule fetches are minimized. > > Not sure how easy that would be to implement though, or what the performance > would be like. That was actually my original recommendation. I've since backed away from it, due to concerns about difficulty in implementation, but if it can be done then this would be rather ideal for most common cases. -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