On Fri, Mar 11, 2016 at 4:41 PM, Junio C Hamano <gits...@pobox.com> wrote: > 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.
Why is it interesting for submodules but not for standard repositories? If I clone a repository without submodules, it is also not recorded that I cloned with an explicit depth=1. If you fetch, you may end up with a deeper history as git fetch doesn't do a "reshallow" to the configured depth. As the depth can easily change I view depth as a measure which is only valid at moment in time, after the operation succeeded we rather want to talk about the cut off points which were introduced by the shallow operation? And these are kept as is by default which is sane. -- 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
