Re: [PATCH 0/2] clone: shallow-submodules should be single-branch by default

From: Bruce Perry <bruce.a.perry@gmail.com>
Date: Jul 3, 2024, 05:00 UTC
Message-ID: <CAJ_CbHX5nyvMy3ZO+YYCWnPhUmS2QZJjTzsePqXT2TEy-LBQfQ@mail.gmail.com>
In-Reply-To: <07d801daccb3$c1de13e0$459a3ba0$@nexbridge.com>

Randall,

Perhaps I was using imprecise terminology. This change should not impact whether submodule clones land in a detached head state, so it should not impact anything that assumes submodule clones are detached head.

The change being made is this: "git clone --recurse-submodules --shallow-submodules" currently gives you a submodule with a detached head at the desired state, but also downloads data for the tips of all branches in the remote being cloned (potentially a lot of unneeded data as in my use case). The modification means the same command would give you a detached head at the desired state, plus the tip of only the default branch in the remote. The modified behavior matches the current behavior for a simple "git clone" followed by "git submodule update --init --recurse--submodules --depth=1".

Thanks, Bruce

(Resent due to a formatting failure)

On Tue, Jul 2, 2024, 1:12 PM <rsbecker@nexbridge.com> wrote:

Show 31 quoted lines

>
> On Tuesday, July 2, 2024 3:08 PM, Bruce Perry wrote:
> >I noticed a couple places where the behavior of recursive clones for shallow
> >submodules does not match what is implied by the documentation. Shallow
> >submodules should be, but aren't, single branch by default. It would also be useful
> >to allow users to override the shallow specification in gitmodules on the command
> >line for clones as they can for submodule update. The modification here for the
> >former is a bit ugly, but hopefully at least gets the point across to start a discussion.
> >First time submitting a patch here, hopefully I'm getting the process right.
> >
> >Bruce Perry (2):
> >  clone: shallow-submodules should be single-branch by default
> >  clone: no-shallow-submodules clone overrides option in gitmodules
> >
> > Documentation/git-clone.txt         |  3 ++
> > Documentation/gitmodules.txt        |  4 +--
> > builtin/clone.c                     | 10 ++++--
> > t/t5614-clone-submodules-shallow.sh | 52 +++++++++++++++++++++++------
> > 4 files changed, 53 insertions(+), 16 deletions(-)
> >
> >
> >base-commit: daed0c68e94967bfbb3f87e15f7c9090dc1aa1e1
> >Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-
> >1740%2Fbaperry2%2Fsubmods-clone-bug-v1
> >Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-
> >1740/baperry2/submods-clone-bug-v1
> >Pull-Request: https://github.com/git/git/pull/1740
>
> I am concerned about this one. Many CI systems (including Jenkins GitSCM) assume a detached head for submodule clone/checkout. Adding a branch to the mix will change the expected semantics. Am I missing something?
> --Randall
>