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

Tor Andersson· Dec 30, 2016, 10:50 UTC · lore

Hi,

When adding submodules with --depth=1 only the master branch is cloned. This often leaves the submodule pointing to a non-existing commit.

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. 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?

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.

-Tor

Stefan Beller· Jan 3, 2017, 19:21 UTC · re: Tor Andersson · lore

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

On Fri, Dec 30, 2016 at 2:50 AM, Tor Andersson <tor@ccxvii.net> wrote:

Show 5 quoted lines

> 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