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 <sbel...@google.com>
---
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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
