On Wed, Nov 11, 2015 at 03:09:18PM +0100, Lars Schneider wrote: > Apparently this does not clone the submodules with "--depth 1" (using Git > 2.4.9). As a workaround I tried: > > git clone --depth 1 --single-branch <url> > cd <repo-name> > git submodule update --init --recursive --depth 1 > > However, this does not work either as I get: > fatal: reference is not a tree: <correct sha1 of the submodule referenced by > the main project> > Unable to checkout <correct sha1 of the submodule referenced by the main > project> in submodule path <submodule path>
This looks like a familiar bug to me. I'm not sure if it's a bug or a known behaviour. When the depth argument was introduced to submodules a year (or two) ago there was a know bug. I not sure if it's fixed or not. The problem is that git is/was unable to fetch a sha1 but only a branch or a tag. So fetching a submodule will fetch the HEAD of the submodule with the requested depth. Then git will try to checkout a sha1 of that submodule, which may or maynot exists. Say that you fetch master of a submodule of depth 1 and do a checkout of a commit that exists. When someonen else has pushed to that submodule, the commit will not longer be reachable from depth 1 and if someone else tries to clone with depth 1 it will fail with the same error message as you got. The solution to this is to allow git to fetch the sha1 the superproject points to direct when fetching the submodule. -- Fredrik Gustafsson phone: +46 733-608274 e-mail: iv...@iveqy.com website: http://www.iveqy.com -- 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
