Re: [PATCH] git-submodule.sh - Remove trailing / from URL if found
From: Junio C Hamano <hidden>
Date: 2016-06-15 22:45:11
Possibly related (same subject, not in this thread)
- 2016-06-15 · Re: [PATCH] git-submodule.sh - Remove trailing / from URL if found · Junio C Hamano <hidden>
- 2016-06-15 · Re: [PATCH] git-submodule.sh - Remove trailing / from URL if found · Mark Levedahl <hidden>
- 2016-06-15 · Re: [PATCH] git-submodule.sh - Remove trailing / from URL if found · Junio C Hamano <hidden>
- 2016-06-15 · [PATCH] git-submodule.sh - Remove trailing / from URL if found · Mark Levedahl <hidden>
- 2016-06-15 · [PATCH] git-submodule.sh - Remove trailing / from URL if found · Mark Levedahl <hidden>
Mark Levedahl [off-list ref] writes:
quoted hunk
git clone does not complain if a trailing '/' is included in the origin URL, but doing so causes resolution of a submodule's URL relative to the superproject to fail. Regardless of whether git is changed to remove the trailing / before recording the URL, we should avoid this issue in submodule as existing repositories can have this problem. Signed-off-by: Mark Levedahl <redacted> --- git-submodule.sh | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)diff --git a/git-submodule.sh b/git-submodule.sh index ea6357b..fa9dd3a 100755 --- a/git-submodule.sh +++ b/git-submodule.sh@@ -34,7 +34,7 @@ resolve_relative_url () remote=$(get_default_remote) remoteurl=$(git config "remote.$remote.url") || die "remote ($remote) does not have a url in .git/config" - url="$1" + url="${1%/}" while test -n "$url" do case "$url" in
Hmm, the case arms outside the context looks like this:
while test -n "$url"
do
case "$url" in
../*)
url="${url#../}"
remoteurl="${remoteurl%/*}"
;;
./*)
url="${url#./}"
;;
*)
break;;
esac
done
echo "$remoteurl/$url"
If you call "resolve_relative_url ../", the first arm used to fire once
and stripped one level away, but with your patch it does not do so
anymore, and returns "$remoteurl/.." instead?
I know you are primarily interested in making sure that "../foo" and
"../foo/" are handled the same way, but somehow this change does not feel
right. How about stripping the trailing slash from the end result?