Jens Lehmann <> writes:

> Am 24.07.2012 21:01, schrieb Justin Spahr-Summers:
>> This occurs on Mac OS X 10.7.4, on git versions (Apple Git-33) and 
>> 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
More majordomo info at

Reply via email to