summaryrefslogtreecommitdiff
path: root/git-submodule.sh
diff options
context:
space:
mode:
authorJonathan Tan <jonathantanmy@google.com>2019-03-13 17:57:38 (GMT)
committerJunio C Hamano <gitster@pobox.com>2019-03-14 00:36:48 (GMT)
commitbd5e567dc75abae58cb364d1e55cbaf67edb8c98 (patch)
tree611dd2c0b366417ab81e9ea0cd61cb8edb470837 /git-submodule.sh
parentaeb582a98374c094361cba1bd756dc6307432c42 (diff)
downloadgit-bd5e567dc75abae58cb364d1e55cbaf67edb8c98.zip
git-bd5e567dc75abae58cb364d1e55cbaf67edb8c98.tar.gz
git-bd5e567dc75abae58cb364d1e55cbaf67edb8c98.tar.bz2
submodule: explain first attempt failure clearly
When cloning with --recurse-submodules a superproject with at least one submodule with HEAD pointing to an unborn branch, the clone goes something like this: Cloning into 'test'... <messages about cloning of superproject> Submodule '<name>' (<uri>) registered for path '<submodule path>' Cloning into '<submodule path>'... fatal: Couldn't find remote ref HEAD Unable to fetch in submodule path '<submodule path>' <messages about fetching with SHA-1> From <uri> * branch <hash> -> FETCH_HEAD Submodule path '<submodule path>': checked out '<hash>' In other words, first, a fetch is done with no hash arguments (that is, a fetch of HEAD) resulting in a "Couldn't find remote ref HEAD" error; then, a fetch is done given a hash, which succeeds. The fetch given a hash was added in fb43e31f2b ("submodule: try harder to fetch needed sha1 by direct fetching sha1", 2016-02-24), and the "Unable to fetch..." message was downgraded from a fatal error to a notice in e30d833671 ("git-submodule.sh: try harder to fetch a submodule", 2018-05-16). This commit improves the notice to be clearer that we are retrying the fetch, and that the previous messages (in particular, the fatal errors from fetch) do not necessarily indicate that the whole command fails. In other words: - If the HEAD-fetch succeeds and we then have the commit we want, git-submodule prints no explanation. - If the HEAD-fetch succeeds and we do not have the commit we want, but the hash-fetch succeeds, git-submodule prints no explanation. - If the HEAD-fetch succeeds and we do not have the commit we want, but the hash-fetch fails, git-submodule prints a fatal error. - If the HEAD-fetch fails, fetch prints a fatal error, and git-submodule informs the user that it will retry by fetching specific commits by hash. - If the hash-fetch then succeeds, git-submodule prints no explanation (besides the ones already printed). - If the HEAD-fetch then fails, git-submodule prints a fatal error. It could be said that we should just eliminate the HEAD-fetch altogether, but that changes some behavior (in particular, some refs that were opportunistically updated would no longer be), so I have left that alone for now. There is an analogous situation with the fetching code in fetch_finish() and surrounding functions. For now, I have added a NEEDSWORK. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'git-submodule.sh')
-rwxr-xr-xgit-submodule.sh2
1 files changed, 1 insertions, 1 deletions
diff --git a/git-submodule.sh b/git-submodule.sh
index b5f2bee..cc750b5 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -593,7 +593,7 @@ cmd_update()
# 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'")"
+ say "$(eval_gettext "Unable to fetch in submodule path '\$displaypath'; trying to directly fetch \$sha1:")"
# Now we tried the usual fetch, but $sha1 may
# not be reachable from any of the refs