On Fri, Feb 05, 2016 at 04:05:01PM -0800, Junio C Hamano wrote: > Stefan Beller <sbeller@xxxxxxxxxx> writes: > > > Currently when cloning a project, including submodules, the --depth argument > > is passed on recursively, i.e. when cloning with "--depth 2", both the > > superproject as well as the submodule will have a depth of 2. It is not > > garantueed that the commits as specified by the superproject are included > > in these 2 commits of the submodule. > > > > Illustration: > > (superproject with depth 2, so A would have more parents, not shown) > > > > superproject/master: A <- B > > / \ > > submodule/master: C <- D <- E <- F <- G > > > > (Current behavior is to fetch G and F) > The --depth option to git submodule is something I've wondered for some time if it was correct to implement it or not. It's clearly not a complete feature yet and it has some weaknesses, the most obvious one stated above. The reason for implementing --depth in submodules was for people having huge (or many) submodules, that they aren't interested in developing in, but need to download to build their project. So they want to save time and bandwidth. My first thought was to implement depth from the sha1 the superproject refered sha1. However, when implementing this, git didn't support fetching a sha1 from a remote repository for security reasons (you should never be allowed to fetch a commit that is not reachable from a branch or tag). Waiting for this to be supported (an (expensive) check could be done if the sha1 asked for exists in any branch or tag), the --depth was added and it's a guessing game on how deep you should fetch. -- Fredrik Gustafsson phone: +46 733-608274 e-mail: iveqy@xxxxxxxxx website: http://www.iveqy.com -- 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