Re: [PATCH] submodule: Fetch the direct sha1 first
- From
Jens Lehmann <jens.lehmann@web.de>
- Date
- Feb 22, 2016, 19:22 UTC
- Message-ID
- <56CB5FDC.5050409@web.de>
- In-Reply-To
- <xmqqvb5k9r5g.fsf@gitster.mtv.corp.google.com>
Am 20.02.2016 um 01:11 schrieb Junio C Hamano:
Show 23 quoted lines
> 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.
Show 6 quoted lines
> 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.