Avoid bug in Solaris xpg4/sed as used in submodule

The sed provided by Solaris in /usr/xpg4/bin has a bug whereby an
unanchored regex using * for zero or more repetitions sees two
separate matches fed to the substitution engine in some cases.

This is evidenced by:

$ for sed in /usr/xpg4/bin/sed /usr/bin/sed /opt/csw/gnu/sed; do \
echo 'ab' | $sed -e 's|[a]*|X|g'; \
done
XXbX
XbX
XbX

This bug was triggered during a git submodule clone operation as
exercised in the setup stage of t5526-fetch-submodules when using the
default SANE_TOOL_PATH for Solaris.  It led to paths such as
..../.. being used in the submodule .git gitdir reference.

Using the expression 's|\([^/]*\(/*\)\)|..\2|g' provides the desired
result with all three three tested sed implementations but is harder
to read.  As we do not need to handle fully qualified paths though,
the expression could actually be [^/]+ which isn't properly handled
either.  Instead, use [^/][^/]*, as suggested by Andreas Schwab, which
works on all three tested sed implementations.

The new expression is semantically different than the original one.
It will not place a leading '..' on a fully qualified path as the
original expression did.  All of the paths being passed through this
regex are relative and did not rely on this behaviour so it's a safe
change.

Signed-off-by: Ben Walton <bwalton@artsci.utoronto.ca>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

1 files changed, 3 insertions, 2 deletions

diff --git a/git-submodule.sh b/git-submodule.sh
index efc86ad4e..3d94a1407 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -167,10 +167,11 @@ module_clone()
 	a=${a%/}
 	b=${b%/}
 
-	rel=$(echo $b | sed -e 's|[^/]*|..|g')
+	# Turn each leading "*/" component into "../"
+	rel=$(echo $b | sed -e 's|[^/][^/]*|..|g')
 	echo "gitdir: $rel/$a" >"$path/.git"
 
-	rel=$(echo $a | sed -e 's|[^/]*|..|g')
+	rel=$(echo $a | sed -e 's|[^/][^/]*|..|g')
 	(clear_local_git_env; cd "$path" && GIT_WORK_TREE=. git config core.worktree "$rel/$b")
 }