Re: Problem with --shallow-submodules option

> Hi,
>
> Thanks for the answer.
> So it means that it is a setting on the server side which can be
> activated? (I guess it depends on the version of the server)
> I did some reading in the topic. Are you talking about this setting
> "uploadpack.allowReachableSHA1InWant", or did I misunderstood what I
> read?

>
> Thanks,
>     Istvan
>
> On 20 June 2016 at 19:45, Stefan Beller <sbeller@google.com> wrote:
>> On Mon, Jun 20, 2016 at 6:06 AM, Istvan Zakar <istvan.zakar@gmail.com> wrote:
>>> Hello,
>>>
>>> I'm working on a relatively big project with many submodules. During
>>> cloning for testing I tried to decrease the amount of data need to be
>>> fetched from the server by using --shallow-submodules option in the clone
>>> command. It seems to check out the tip of the remote repo, and if it's not
>>> the commit registered in the superproject the submodule update fails
>>> (obviously).
>>
>> Yes that is broken as the depth of a submodule is counted from its own HEAD
>> not from the superprojects sha1 as it should.
>>
>> So it does
>>
>>     git clone --depth=1 <submodule-url> <submodule-path>
>>
>>     if HEAD != recorded gitlink sha1,
>>         git fetch <recorded gitlink sha1>
>>
>>     git checkout <recorded gitlink sha1>
>>
>>> Can I somehow tell to fetch that exact commit I need for my
>>> superproject?
>>
>> Some servers support fetching by direct sha1, which is what we make use
>> of here, then it sort-of works.
>>
>> If the server doesn't support the capability to fetch an arbitrary sha1,
>> the submodule command fails, with a message such as
>>
>>     error: no such remote ref $sha1
>>     Fetched in submodule path '<submodule>', but it did not contain
>> $sha1. Direct fetching of that commit failed.
>>
>> So if it breaks for you now, I would suggest not using that switch, I
>> don't think there is a quick
>> workaround.
>>
>>>
>>> Thanks,
>>>    Istvan
>>
>> Thanks,
>> Stefan
>>
>>>
>>> --
>>> 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