Re: [RFC PATCH] git-submodule.sh:cmd_update: if submodule branch exists, fetch that instead of default

From

Stefan Beller <sbeller@google.com>

Date

Mar 26, 2018, 23:06 UTC

Message-ID

<CAGZ79kb4Ea7t5j9XA0key1f99w5xRDwyRhMder1FMgdiZot3Tg@mail.gmail.com>

In-Reply-To

<1520366804-28233-1-git-send-email-eddy.petrisor@gmail.com>

[snipped the cc list as well]

> Signed-off-by: Eddy Petrișor <eddy.petrisor@gmail.com>
> ---

> There are projects such as llvm/clang which use several repositories, and

they

> might be forked for providing support for various features such as adding

Redox

> awareness to the toolchain. This typically means the superproject will use
> another branch than master, occasionally even use an old commit from that
> non-master branch.

> Combined with the fact that when incorporating such a hierachy of

repositories

> usually the user is interested in just the exact commit specified in the
> submodule info, it follows that a desireable usecase is to be also able to
> provide '--depth 1' to avoid waiting for ages for the clone operation to
> finish.

Very sensible.

> Git submodule seems to be very stubborn and cloning master, although the
> wrapper script and the gitmodules-helper could work together to clone

directly

> the branch specified in the .gitmodules file, if specified.

Also very sensible.

> Another wrinkle is that when the commit is not the tip of the branch, the

depth

> parameter should somehow be stored in the .gitmodules info, but any

change in

> the submodule will break the supermodule submodule depth info sooner or

later,

> which is definitly frigile.

... which is why I would not include that.

> I tried digging into this section of the code and debugging with bashdb

to see

> where --depth might fit, but I got stuck on the shell-to-helper

interaction and

> the details of the submodule implementation, so I want to lay out this

first

> patch as starting point for the discussion in the hope somebody else

picks it

> up or can provide some inputs. I have the feeling there are multiple code

paths

> that are being ran, depending on the moment (initial clone, submodule
> recursive, post-clone update etc.) and I have a gut feeling there

shouldn't be

> any code duplication just because the operation is different.

> This first patch is only trying to use a non-master branch, I have some

changes

> for the --depth part, but I stopped working on it due to the "default

depth"

> issue above.

> Does any of this sound reasonable?
> Is this patch idea usable or did I managed to touch the part of the code

that

> should not be touched?

This sounds reasonable. Thanks for writing the patch!

> diff --git a/git-submodule.sh b/git-submodule.sh
> index 2491496..370f19e 100755
> --- a/git-submodule.sh
> +++ b/git-submodule.sh
> @@ -589,8 +589,11 @@ cmd_update()
>                          branch=$(git submodule--helper remote-branch

"$sm_path")

>                          if test -z "$nofetch"
>                          then
> +                               # non-default branch
> +                               rbranch=$(git config -f .gitmodules

submodule.$sm_path.branch)

> +

br_refspec=${rbanch:+"refs/heads/$rbranch:refs/heads/$rbranch"}

     br_refspec=$(git submodule--helper remote-branch $sm_path)

I would think.

>                                  # Fetch remote before determining

tracking $sha1

> -                               fetch_in_submodule "$sm_path" $depth ||
> +                               fetch_in_submodule "$sm_path" $depth

$br_refspec ||

>                                  die "$(eval_gettext "Unable to fetch in

submodule path '\$sm_path'")"

>                          fi
>                          remote_name=$(sanitize_submodule_env; cd

"$sm_path" && get_default_remote)