+cc Stanislav, who came up with the other thread for passing --remote
to git submodule
On Thu, Nov 12, 2015 at 1:39 AM, Lars Schneider
<larsxschneider@xxxxxxxxx> wrote:
>> Notice the other email thread, which suggests to include --remote into the
>> call to git submodule update depending on a branch config option being
>> present in the .gitmodules file.
>
> Can you check "[PATCH v2] add test to demonstrate that shallow recursive clones fail"? This demonstrates the failure that I see. I also tried the "--remote" flag but this does not work either (see test case).
> Can you confirm this behavior?
>
> Cheers,
> Lars
I can confirm it breaks as expected here.
I may have confused you here by pointing to the --remote option.
(git clone is a bit stupid when it comes to submodule handling.)
All it does currently is this:
if --recurseSubmodules option or --recursive option is given:
run: "git submodule update --init --recursive"
No attention is paid to any other option such as --depth.
That's all I wanted to point out there.
Ideally we want to add:
If there is a branch configured in the .gitmodules file,
we would want to add the --remote command
if we have given other options such as --depth or --reference
we want to pass that along to the called submodule helper.
So I was looking at the internal code structure and think one of the next
series I am going to send will touch the code such that we can incorporate
the conditions as outlined above easier, because it is not hardcoded into an
array ["git", "submodule", "update" "--init", "--recursive"], as I
want to add yet
another dynamic option to the submodule helper invocation. (I want to add
--jobs <n> there)
Cheers,
Stefan
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html