Jens Lehmann <Jens.Lehmann@xxxxxx> writes: > Am 24.07.2012 21:01, schrieb Justin Spahr-Summers: >> This occurs on Mac OS X 10.7.4, on git versions 1.7.10.2 (Apple Git-33) and 1.7.11.3. >> >> Steps: >> 1. Create or clone a repository to an absolute path that contains spaces. >> 2. Add a submodule to the repository, if it does not already have one. >> 3. Within that submodule, attempt to add another submodule. >> >> The result is an error "fatal: Not a git repository", followed by the relative path to the submodule directory within .git/modules of the top-level repository. >> >> Similarly, using "git submodule update --init --recursive" in a freshly-cloned repository that matches the above configuration will fail with the same error. "git clone --recursive" does not seem to suffer from the same problem at clone time, but will still fail to add recursive submodules. > > Hmm, I don't understand how that is different from what t7407 does, it uses > "git submodule update --init --recursive" in to populate recursive submodules > in a freshly cloned repository whose path contains a space (in the trash > directory name) in test number 8. I can see one codepath that would behave incorrectly, especially if the submodule path relative to the superproject has whitespaces in it. In module_clone(), you have: # We already are at the root of the work tree but cd_to_toplevel will # resolve any symlinks that might be present in $PWD a=$(cd_to_toplevel && cd "$gitdir" && pwd)/ b=$(cd_to_toplevel && cd "$sm_path" && pwd)/ ... # Turn each leading "*/" component into "../" rel=$(echo $b | sed -e 's|[^/][^/]*|..|g') echo "gitdir: $rel/$a" >"$sm_path/.git" I _think_ $sm_path is computed correctly by the codeflow leading to this place, and $b is also computed correctly, but notice the lack of quoting around $b when you echo it? It will be split at $IFS, so if b='/Program Files/My Stupidity/', the sed script will see a single SP between My and Stupidity, which is different from what you wanted to feed, I presume. Having said that, I do not think git-submodule is prepared to take paths with path-unsafe characters in it, given that many part of it has loops like "while read mode sha1 stage sm_path" that reads from ls-files/ls-tree output without -z (which means it cannot handle pathnames with LF in them). My recommendation at this point (i.e. not a long term) for people with problems Justin saw is "Don't do it then". -- 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