Re: Wanted: shallow submodule clones with --no-single-branch.

On Fri, Dec 30, 2016 at 2:50 AM, Tor Andersson [off-list ref] 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