On Oct 13, 2010, at 1:06 PM, Jens Lehmann wrote: > Am 13.10.2010 21:34, schrieb Kevin Ballard: >> On Oct 13, 2010, at 12:32 PM, Jens Lehmann wrote: >> >>>>> There are use cases like mine where automatic recursion is just the right >>>>> thing to do. But I would be fine with having to turn the recursion on >>>>> explicitly in the configuration if most people think recursion is not a >>>>> desirable default. It would be really nice to hear from other submodule >>>>> users what they think about that ... >>>> >>>> I tend to think that the right default for fetch is to employ the same level >>>> of recursion that was used for the initial clone. So if the clone was made >>>> with --recursive then fetch should default to using --recursive. >>> >>> That's a very interesting idea. >> >> 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. > > For *your* use case it might not be correct, but for others it may very > well be. My inclination is to say recursively fetching submodules is a choice many maintainers may want to make, but not something any simple user of a repo will want to do. If I find a neat project out there and `git clone --recursive` it, there's no reason to believe I'll want to track updates to its submodules, as I have no plans on ever modifying this repo myself or creating any commits. -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