On Mon, Aug 6, 2018 at 10:41 AM, Jonathan Nieder <jrnie...@gmail.com> wrote: > Robert Dailey wrote: > >> Automatic would be >> great if submodules were treated as integrated in a similar manner to >> subtree, but it's not there. I wasn't aware that `submodule update` >> did a fetch, because sometimes if I do that, I get errors saying SHA1 >> is not present (because the submodule did not get fetched). Granted I >> haven't seen this in a while, so maybe the fetch on submodule update >> is a newer feature. Do you know what triggers the fetch on update >> without --remote? Is it the missing SHA1 that triggers it, or is it >> fetching unconditionally? > > Thanks for this and the rest of the context you sent. It's very > helpful. > > The relevant code in git-submodule.sh is > > # Run fetch only if $sha1 isn't present or it > # is not reachable from a ref. > is_tip_reachable "$sm_path" "$sha1" || > fetch_in_submodule "$sm_path" $depth || > say "$(eval_gettext "Unable to fetch in submodule path > '\$displaypath'")" > > # Now we tried the usual fetch, but $sha1 may > # not be reachable from any of the refs > is_tip_reachable "$sm_path" "$sha1" || > fetch_in_submodule "$sm_path" $depth "$sha1" || > die "$(eval_gettext "Fetched in submodule path '\$displaypath', but > it did not contain \$sha1. Direct fetching of that commit failed.")" > > The fallback to fetching by SHA-1 was introduced in v2.8.0-rc0~9^2 > (submodule: try harder to fetch needed sha1 by direct fetching sha1, > 2018-02-23).
Yep, that's the root cause; I was basing my concerns on a legacy issue. I just had avoided using `update` when I expected a fetch, so I never saw the issue again, and thus didn't realize it was corrected. Very helpful. Thanks again!
