git-submodule.sh: try harder to fetch a submodule

This is the logical continuum of fb43e31f2b4 (submodule: try harder to fetch needed sha1 by direct fetching sha1, 2016-02-23) and fixes it as some assumptions were not correct. The commit states: > If $sha1 was not part of the default fetch ... fail ourselves here > assumes that the fetch_in_submodule only fails when the serverside does > not support fetching by sha1. There are other failures, why such a fetch may fail, such as fatal: Couldn't find remote ref HEAD which can happen if the remote side doesn't advertise HEAD and we do not have a local fetch refspec. Not advertising HEAD is allowed by the protocol spec and would happen, if HEAD points at an unborn branch for example. Not having a local fetch refspec can happen when submodules are fetched shallowly, as then git-clone doesn't setup a fetch refspec. So do try even harder for a submodule by ignoring the exit code of the first fetch and rather relying on the following is_tip_reachable to see if we try fetching again. Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>

Stefan Beller committed May 15, 2018 at 12:40 UTC e30d833671d634ea6455fd49596ac7339a4915b1
1 file changed +1 -1
git-submodule.sh
+1 -1
@@ -614,7 +614,7 @@ cmd_update()
614 # is not reachable from a ref.
615 is_tip_reachable "$sm_path" "$sha1" ||
616 fetch_in_submodule "$sm_path" $depth ||
617 - die "$(eval_gettext "Unable to fetch in submodule path '\$displaypath'")"
617 + say "$(eval_gettext "Unable to fetch in submodule path '\$displaypath'")"
618
619 # Now we tried the usual fetch, but $sha1 may
620 # not be reachable from any of the refs