From: Stefan Beller <sbeller@google.com>
Date: Wed, 11 Nov 2015 19:48:08 GMT
Subject: Re: git clone --recursive should run git submodule update with flag --remote
Message-ID: <CAGZ79kbOyXm11uPCXcDJzKxbQzBx6ZOmq0TS8kc52xy-qV_FiQ@mail.gmail.com>
In-Reply-To: <loom.20151111T133121-436@post.gmane.org>

On Wed, Nov 11, 2015 at 4:46 AM, Stanislav <s.seletskiy@gmail.com> wrote:
> Consider two repositories, A and B.
>
> Repo A is embedded into B by using submodule:
>
>   git submodule add -b master <url-to-A> sub-a
>
> So, submodule sub-a is set to track master branch of the repo A.
>
> Running git submodule update --remote inside repo B will automatically
> update and checkout submodule sub-a to the latest master commit (as expected).
>
> However, when using git clone --recursive <url-to-B>, repo B will be cloned
> with submodule A checkouted to the commmit which was recorded on git
> submodule add command, not the master commit.
>
> Expected behaviour is to automatically update checkout commit pointed by
> branch, that was specified by -b flag in the git submodule add invocation.

To achieve what you want to do, you can first clone B and then
do a `git submodule update` using the --remote option yourself.
That is cumbersome however, I agree.

>
> Reason for this behaviour is that line:
>
>   https://github.com/git/git/blob/master/builtin/clone.c#L99
>
> I guess, it should be changed to include --remote flag.

I guess we could tweak the behavior to include the --remote flag
when the branch is recorded in the .gitmodules file.

Just wondering what should happen if there are both a sha1
and a branch recorded?

>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html