Stefan Beller <sbel...@google.com> writes: > When creating a shallow clone of a repository with submodules, the depth > argument does not influence the submodules, i.e. the submodules are done > as non-shallow clones. It is unclear what the best default is for the > depth of submodules of a shallow clone, so we need to have the possibility > to do all kinds of combinations: > > * shallow super project with shallow submodules > e.g. build bots starting always from scratch. They want to transmit > the least amount of network data as well as using the least amount > of space on their hard drive. > * shallow super project with unshallow submodules > e.g. The superproject is just there to track a collection of repositories > and it is not important to have the relationship between the repositories > intact. However the history of the individual submodules matter. > * unshallow super project with shallow submodules > e.g. The superproject is the actual project and the submodule is a > library which is rarely touched. > > The new switch to select submodules to be shallow or unshallow supports > all of these three cases.
I think something like this is necessary to prime the well, but the more important (and intereseting) bit is how this shallowness is going to be maintained and carried forward across the future updates to the top-level supermodule. A submodule that was cloned at depth=1 initially along with its supermodule when the latter was initially cloned does not have to be indefinitely kept at depth=1, and there would be a lot of creative ways to make it useful, but the creative and useful logic would need a piece of information to tell the future "submodule update" why the submodule repository is shallow to take into account, I would imagine. It is somewhat curious that there is no hint left in the submodule repositories (e.g. their configfile) that they are originally created with an explicit user request "I said that I want these submodules to be cloned with depth=1", from that point of view. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
