Am 20.02.2016 um 01:11 schrieb Junio C Hamano:
Stefan Beller <sbeller@xxxxxxxxxx> writes:On Fri, Feb 19, 2016 at 2:29 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:Stefan Beller <sbeller@xxxxxxxxxx> 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.
--
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