When reviewing a change in Gerrit, which also updates a submodule, a common review practice is to download and cherry-pick the patch locally to test it. However when testing it locally, the 'git submodule update' may fail fetching the correct submodule sha1 as the corresponding commit in the submodule is not yet part of the project history, but also just a proposed change. To ease this, try fetching by sha1 first and when that fails (in case of servers which do not allow fetching by sha1), fall back to the default behavior we already have. Signed-off-by: Stefan Beller <sbeller@xxxxxxxxxx> --- I think it's best to apply this on origin/master, there is no collision with sb/submodule-parallel-update. Also I do not see a good way to test this both in correctness as well as performance degeneration. If the first git fetch fails, the second fetch is executed, so it should behave as before this patch w.r.t. correctness. Regarding performance, the first fetch should fail quite fast iff the fetch fails and then continue with the normal fetch. In case the first fetch works fine getting the exact sha1, the fetch should be faster than a default fetch as potentially less data needs to be fetched. Thanks, Stefan git-submodule.sh | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/git-submodule.sh b/git-submodule.sh index 9bc5c5f..ee0b985 100755 --- a/git-submodule.sh +++ b/git-submodule.sh @@ -746,8 +746,9 @@ Maybe you want to use 'update --init'?")" # Run fetch only if $sha1 isn't present or it # is not reachable from a ref. (clear_local_git_env; cd "$sm_path" && + remote_name=$(get_default_remote) ( (rev=$(git rev-list -n 1 $sha1 --not --all 2>/dev/null) && - test -z "$rev") || git-fetch)) || + test -z "$rev") || git-fetch $remote_name $rev || git-fetch)) || die "$(eval_gettext "Unable to fetch in submodule path '\$displaypath'")" fi -- 2.7.0.rc0.34.ga06e0b3.dirty -- 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