Re: Bug with git-submodule and IFS

Andrew Dranse [off-list ref] writes:

Hi there,

I ran into an interesting bug with git submodules today.  It
appears that if your IFS is not set to what git-submodule expects
it to be (i.e. the standard IFS), it will break in a fun way.

Example:

$ git init
Initialized empty Git repository in /home/adranse/test/.git/
$ git submodule add github:/repos/perf
Cloning into 'perf'...
remote: Counting objects: 5744, done.
remote: Compressing objects: 100% (4627/4627), done.
remote: Total 5744 (delta 2400), reused 1579 (delta 343)
Receiving objects: 100% (5744/5744), 28.78 MiB | 4.56 MiB/s, done.
Resolving deltas: 100% (2400/2400), done.
$ export IFS="

quoted

"

$ git submodule update --init --recursive
No submodule mapping found in .gitmodules for path ''

I do not think it is limited to "git submodule", and shell scripts
generally, not limited to shell scripted Porcelain commands from the
Git suite, assume that they can rely safely on words split at SP and
HT.

Perhaps something like this is a good solution for it.

 git-sh-setup.sh | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/git-sh-setup.sh b/git-sh-setup.sh
index 770a86e..ee0e0bc 100644
--- a/git-sh-setup.sh
+++ b/git-sh-setup.sh

@@ -9,8 +9,12 @@
 # you would cause "cd" to be taken to unexpected places.  If you
 # like CDPATH, define it for your interactive shell sessions without
 # exporting it.
+# But we protect ourselves from such a user mistake nevertheless.
 unset CDPATH
 
+# Similarly for IFS
+unset IFS
+
 git_broken_path_fix () {
 	case ":$PATH:" in
 	*:$1:*) : ok ;;