Re: [PATCH] submodule: Fetch the direct sha1 first

[Jens Lehmann <Jens.Lehmann@web.de>]

Am 20.02.2016 um 01:11 schrieb Junio C Hamano:
> Stefan Beller <sbeller@google.com> writes:
>
>> On Fri, Feb 19, 2016 at 2:29 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>> Stefan Beller <sbeller@google.com> writes:
>>>
>>>> Doing a 'git fetch' only and not the fetch for the specific sha1 would be
>>>> incorrect?
>>>
>>> I thought that was what you are attempting to address.
>>
>> Yep. In an ideal world I would imagine it would look like
>>
>>      if $sha1 doesn't exist:
>>          fetch $sha1
>>          if server did not support fetching direct sha1:
>>              fallback to fetch <no args>
>
> It should look more like this:
>
> 	if $sha1's history and objects are incomplete:
> 		fetch ;# normally just like we have done before
>                  if $sha1's history and objects are still incomplete:
> 			fetch $sha1

That makes lots of sense, doesn't break existing workflows and
enables the use case Stefan described. And if people want to skip
the first fetch later we could still add a config option to do so.

> as existing users already expect that commits and objects that are
> reachable from tips of refs configured to be fetched in the
> submodule via its configured refspecs are available after this part
> of the code runs, regardless of this "Gerrit reviews may not have
> arrived to branches yet" issue.  The first "normal" fetch ensures
> that the expectation is met.

Not sure if that has come up so far, but I believe we should not
only do that for the submodule command but also for a regular
fetch when it is configured to fetch submodule commits too (which
it is by default unless configured otherwise). Otherwise we'll
lose the plane-safety fetch normally provides in case of these
unconnected submodule sha1s, which would then again break users
expectations.

And if we see demand for only fetching the sha1s without any
extra history in the future (e.g. to minimize the amount of data
to be fetched by a CI server), we could add a new value ("by-sha1"
or such) for both the --recurse-submodules option of fetch and
pull and the submodule.<name>.fetchRecurseSubmodules config
setting. Then both a git submodule update and fetch would attempt
to just fetch the sha1(s) needed without any fetching any extra
history.