Hi, Robert Dailey wrote: > Problem: I want to avoid recursively fetching submodules when I run a > `fetch` command, and instead defer that operation to the next > `submodule update`. Essentially I want `fetch.recurseSubmodules` to be > `false`, and `get submodule update` to do exactly what it does with > the `--remote` option, but still use the SHA1 of the submodule instead > of updating to the tip of the specified branch in the git modules > config. > > I hope that makes sense. The reason for this ask is to > improve/streamline workflow in parent repositories. There are cases > where I want to quickly fetch only the parent repository, even if a > submodule changes, to perform some changes that do not require the > submodule itself (yet). Then at a later time, do `submodule update` > and have it automatically fetch when the SHA1 it's updating to does > not exist (because the former fetch operation for the submodule was > skipped). For my case, it's very slow to wait on submodules to > recursively fetch when I only wanted to fetch the parent repo for the > specific task I plan to do. > > Is this possible right now through some variation of configuration? Can you say more about the overall workflow? This seems quite different from what we've been designing --recurse-submodules around: - avoiding the end user ever having to use the "git submodule" command, except to add, remove, or reconfigure submodules - treating the whole codebase as something like one project, so that "git checkout --recurse-submodules <commit>" always checks out the same state More details about the application would help with better understanding whether it can fit into this framework, or whether it's a case where you'd want to set "submodule.recurse" to false to have more manual control. Thanks and hope that helps, Jonathan
