From: Kevin Ballard Date: Wed, 13 Oct 2010 20:11:34 GMT Subject: Re: [PATCH v2 0/3] Teach fetch and pull to recursively fetch submodules too Message-ID: <2C7BF9BF-870D-40B8-8379-8168FCDD2B64@sb.org> In-Reply-To: <4CB61137.6030502@web.de> 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