On Fri, Dec 30, 2016 at 2:50 AM, Tor Andersson <tor@xxxxxxxxxx> wrote: > Hi, > > When adding submodules with --depth=1 only the master branch is > cloned. This often leaves the submodule pointing to a non-existing > commit. You can also use the "--branch=not_master" flag to track another branch. This however doesn't clone the correct branch. I would have expected that it cloned the correct branch instead. > > It would be useful if I could pass the --no-single-branch argument to > the submodule clone process, since then a submodule can point to any > tag or branch without ending up in this situation. Adding --no-single-branch sounds like a good idea for general use, but it seems like a clunky workaround when looking for a specific branch, i.e. fixing the --branch flag sounds like the right approach for this issue here? > I've got a local > patch to hardwire the --no-single-branch argument in the > builtin/submodule--helper.c clone_submodule function, but I'm not sure > if this will have any other adverse effects? Well, when asking for depth=1, the user usually actually wants to have the least amount of data, which is why --depth implies --single-branch in clone. So adding it unconditionally is a bad idea IMHO, we'd need to have a flag for that propagated from git-submodule.sh (function cmd_add) to the submodule--helpers module_clone. > > Better yet would be for the shallow submodule clone to automatically > retrieve and graft the actual commit the submodule points to, but > that's probably wishing for too much. I think fixing the branch option comes a bit closer, but still doesn't fix this root problem. "submodule update" tries to fetch by sha1 directly in the hope that the server has uploadpack.\ allowReachableSHA1InWant configured. In "submodule add" I think it is sufficient to take the current remotes $branch and record that, so I do not see the need in the add code to support direct sha1s unlike the update command? Thanks, Stefan