{"thread":{"id":"31086","subject":"Bug: Recursive submodules fail when the repo path contains spaces","startedAt":"2012-07-24T19:01:30Z","lastAt":"2012-07-29T21:13:55Z","messageCount":12,"participants":["Justin Spahr-Summers","Jens Lehmann","Junio C Hamano","Heiko Voigt","Phil Hord"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"195643","messageId":"1CE02EC2D88646D48EE7B7D71AD36234@gmail.com","threadId":"31086","inReplyTo":null,"subject":"Bug: Recursive submodules fail when the repo path contains spaces","fromName":"Justin Spahr-Summers","fromEmail":"justin.spahrsummers@gmail.com","sentAt":"2012-07-24T19:01:30Z","receivedAt":"2012-07-24T19:01:30Z","isPatch":false,"sender":{"key":"justin.spahrsummers@gmail.com","avatar":"https://gravatar.com/avatar/2b9de55d3726992f28e8c88424641352911c174cb6561a125feb733affd598ba?d=mp&s=160"},"body":"This occurs on Mac OS X 10.7.4, on git versions 1.7.10.2 (Apple Git-33) and 1.7.11.3.\n\nSteps:\n 1. Create or clone a repository to an absolute path that contains spaces.\n 2. Add a submodule to the repository, if it does not already have one.\n 3. Within that submodule, attempt to add another submodule.\n\nThe 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.\n\nSimilarly, 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.\n\n-- \nJustin Spahr-Summers\n"},{"id":"195654","messageId":"500F00C7.4040209@web.de","threadId":"31086","inReplyTo":"1CE02EC2D88646D48EE7B7D71AD36234@gmail.com","subject":"Re: Bug: Recursive submodules fail when the repo path contains spaces","fromName":"Jens Lehmann","fromEmail":"jens.lehmann@web.de","sentAt":"2012-07-24T20:08:39Z","receivedAt":"2012-07-24T20:08:39Z","isPatch":false,"sender":{"key":"jens.lehmann@web.de","avatar":"https://avatars.githubusercontent.com/u/135220?v=4"},"body":"Am 24.07.2012 21:01, schrieb Justin Spahr-Summers:\n> This occurs on Mac OS X 10.7.4, on git versions 1.7.10.2 (Apple Git-33) and 1.7.11.3.\n> \n> Steps:\n>  1. Create or clone a repository to an absolute path that contains spaces.\n>  2. Add a submodule to the repository, if it does not already have one.\n>  3. Within that submodule, attempt to add another submodule.\n> \n> 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.\n> \n> 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.\n\nHmm, I don't understand how that is different from what t7407 does, it uses\n\"git submodule update --init --recursive\" in to populate recursive submodules\nin a freshly cloned repository whose path contains a space (in the trash\ndirectory name) in test number 8.\n\nDoes the git test suite succeed for you?\n"},{"id":"195655","messageId":"7va9yogb37.fsf@alter.siamese.dyndns.org","threadId":"31086","inReplyTo":"500F00C7.4040209@web.de","subject":"Re: Bug: Recursive submodules fail when the repo path contains spaces","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-07-24T20:26:04Z","receivedAt":"2012-07-24T20:26:04Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jens Lehmann <Jens.Lehmann@web.de> writes:\n\n> Am 24.07.2012 21:01, schrieb Justin Spahr-Summers:\n>> This occurs on Mac OS X 10.7.4, on git versions 1.7.10.2 (Apple Git-33) and 1.7.11.3.\n>> \n>> Steps:\n>>  1. Create or clone a repository to an absolute path that contains spaces.\n>>  2. Add a submodule to the repository, if it does not already have one.\n>>  3. Within that submodule, attempt to add another submodule.\n>> \n>> 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.\n>> \n>> 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.\n>\n> Hmm, I don't understand how that is different from what t7407 does, it uses\n> \"git submodule update --init --recursive\" in to populate recursive submodules\n> in a freshly cloned repository whose path contains a space (in the trash\n> directory name) in test number 8.\n\nI can see one codepath that would behave incorrectly, especially if\nthe submodule path relative to the superproject has whitespaces in\nit.  In module_clone(), you have:\n\n\t# We already are at the root of the work tree but cd_to_toplevel will\n\t# resolve any symlinks that might be present in $PWD\n\ta=$(cd_to_toplevel && cd \"$gitdir\" && pwd)/\n\tb=$(cd_to_toplevel && cd \"$sm_path\" && pwd)/\n\t...\n\t# Turn each leading \"*/\" component into \"../\"\n\trel=$(echo $b | sed -e 's|[^/][^/]*|..|g')\n\techo \"gitdir: $rel/$a\" >\"$sm_path/.git\"\n\nI _think_ $sm_path is computed correctly by the codeflow leading to\nthis place, and $b is also computed correctly, but notice the lack\nof quoting around $b when you echo it?  It will be split at $IFS, so\nif b='/Program Files/My  Stupidity/', the sed script will see a\nsingle SP between My and Stupidity, which is different from what you\nwanted to feed, I presume.\n\nHaving said that, I do not think git-submodule is prepared to take\npaths with path-unsafe characters in it, given that many part of it\nhas loops like \"while read mode sha1 stage sm_path\" that reads from\nls-files/ls-tree output without -z (which means it cannot handle\npathnames with LF in them).\n\nMy recommendation at this point (i.e. not a long term) for people\nwith problems Justin saw is \"Don't do it then\".\n"},{"id":"195656","messageId":"D842C9D621F44E398A1145EC1B67580C@gmail.com","threadId":"31086","inReplyTo":"500F00C7.4040209@web.de","subject":"Re: Bug: Recursive submodules fail when the repo path contains spaces","fromName":"Justin Spahr-Summers","fromEmail":"justin.spahrsummers@gmail.com","sentAt":"2012-07-24T20:30:31Z","receivedAt":"2012-07-24T20:30:31Z","isPatch":false,"sender":{"key":"justin.spahrsummers@gmail.com","avatar":"https://gravatar.com/avatar/2b9de55d3726992f28e8c88424641352911c174cb6561a125feb733affd598ba?d=mp&s=160"},"body":"On Tuesday, 24. July 2012 at 13:08, Jens Lehmann wrote:\n> Am 24.07.2012 21:01, schrieb Justin Spahr-Summers:\n> > This occurs on Mac OS X 10.7.4, on git versions 1.7.10.2 (Apple Git-33) and 1.7.11.3.\n> >  \n> > Steps:\n> > 1. Create or clone a repository to an absolute path that contains spaces.\n> > 2. Add a submodule to the repository, if it does not already have one.\n> > 3. Within that submodule, attempt to add another submodule.\n> >  \n> > 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.\n> >  \n> > 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.\n>  \n> Hmm, I don't understand how that is different from what t7407 does, it uses\n> \"git submodule update --init --recursive\" in to populate recursive submodules\n> in a freshly cloned repository whose path contains a space (in the trash\n> directory name) in test number 8.\n>  \n> Does the git test suite succeed for you?  \nThe only test that fails is:  \n\n*** t7501-commit.sh ***\n*** t7502-commit.sh ***\n…\nnot ok - 13 commit message from template with whitespace issue\n\n\n\n(which I assume is unrelated)\n"},{"id":"195657","messageId":"9ADC1C4EF43A4237BC7971884C50C0EB@gmail.com","threadId":"31086","inReplyTo":"7va9yogb37.fsf@alter.siamese.dyndns.org","subject":"Re: Bug: Recursive submodules fail when the repo path contains spaces","fromName":"Justin Spahr-Summers","fromEmail":"justin.spahrsummers@gmail.com","sentAt":"2012-07-24T20:33:44Z","receivedAt":"2012-07-24T20:33:44Z","isPatch":false,"sender":{"key":"justin.spahrsummers@gmail.com","avatar":"https://gravatar.com/avatar/2b9de55d3726992f28e8c88424641352911c174cb6561a125feb733affd598ba?d=mp&s=160"},"body":"On Tuesday, 24. July 2012 at 13:26, Junio C Hamano wrote:\n> Jens Lehmann <Jens.Lehmann@web.de (http://web.de)> writes:\n> \n> > Am 24.07.2012 21:01, schrieb Justin Spahr-Summers:\n> > > This occurs on Mac OS X 10.7.4, on git versions 1.7.10.2 (Apple Git-33) and 1.7.11.3.\n> > > \n> > > Steps:\n> > > 1. Create or clone a repository to an absolute path that contains spaces.\n> > > 2. Add a submodule to the repository, if it does not already have one.\n> > > 3. Within that submodule, attempt to add another submodule.\n> > > \n> > > 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.\n> > > \n> > > 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.\n> > \n> > Hmm, I don't understand how that is different from what t7407 does, it uses\n> > \"git submodule update --init --recursive\" in to populate recursive submodules\n> > in a freshly cloned repository whose path contains a space (in the trash\n> > directory name) in test number 8.\n> \n> \n> \n> I can see one codepath that would behave incorrectly, especially if\n> the submodule path relative to the superproject has whitespaces in\n> it. In module_clone(), you have:\n> \n> # We already are at the root of the work tree but cd_to_toplevel will\n> # resolve any symlinks that might be present in $PWD\n> a=$(cd_to_toplevel && cd \"$gitdir\" && pwd)/\n> b=$(cd_to_toplevel && cd \"$sm_path\" && pwd)/\n> ...\n> # Turn each leading \"*/\" component into \"../\"\n> rel=$(echo $b | sed -e 's|[^/][^/]*|..|g')\n> echo \"gitdir: $rel/$a\" >\"$sm_path/.git\"\n> \n> I _think_ $sm_path is computed correctly by the codeflow leading to\n> this place, and $b is also computed correctly, but notice the lack\n> of quoting around $b when you echo it? It will be split at $IFS, so\n> if b='/Program Files/My Stupidity/', the sed script will see a\n> single SP between My and Stupidity, which is different from what you\n> wanted to feed, I presume.\n> \n> Having said that, I do not think git-submodule is prepared to take\n> paths with path-unsafe characters in it, given that many part of it\n> has loops like \"while read mode sha1 stage sm_path\" that reads from\n> ls-files/ls-tree output without -z (which means it cannot handle\n> pathnames with LF in them).\n> \n> My recommendation at this point (i.e. not a long term) for people\n> with problems Justin saw is \"Don't do it then\".\n\nI appreciate the debugging work. Unfortunately, none of the relative submodule paths have had whitespace in them, so I'm not sure that's the issue. \n\nHere's some real output, with a couple specific names removed, starting from the root of the top-level repository (where External/twui is a submodule):\n\n$ cd External/twui\n$ git submodule add git://github.com/petejkim/expecta.git TwUITests/expecta\nCloning into 'TwUITests/expecta'...\nremote: Counting objects: 988, done.\nremote: Compressing objects: 100% (404/404), done.\nremote: Total 988 (delta 680), reused 842 (delta 535)\nReceiving objects: 100% (988/988), 156.30 KiB, done.\nResolving deltas: 100% (680/680), done.\nfatal: Not a git repository: ../../../../../../../../Volumes/drive name with spaces/Users/justin/Documents/Programming/project name with spaces/.git/modules/External/twui/modules/TwUITests/expecta\n"},{"id":"195658","messageId":"7v629cgajh.fsf@alter.siamese.dyndns.org","threadId":"31086","inReplyTo":"9ADC1C4EF43A4237BC7971884C50C0EB@gmail.com","subject":"Re: Bug: Recursive submodules fail when the repo path contains spaces","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-07-24T20:37:54Z","receivedAt":"2012-07-24T20:37:54Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Justin Spahr-Summers <justin.spahrsummers@gmail.com> writes:\n\n> On Tuesday, 24. July 2012 at 13:26, Junio C Hamano wrote:\n> ...\n>> I can see one codepath that would behave incorrectly,...\n>> ...\n>> My recommendation at this point (i.e. not a long term) for people\n>> with problems Justin saw is \"Don't do it then\".\n>\n> I appreciate the debugging work.\n\nThat was not a debug, and I didn't mean to say that was the only\nplace that is problematic.  In fact I think I said the script is not\nprepared to work with paths with paths-unsafe characters because it\nhas many problematic constructs, and ended the message with \"Don't\ndo it then\".\n"},{"id":"196034","messageId":"20120728162132.GC98893@book.hvoigt.net","threadId":"31086","inReplyTo":"9ADC1C4EF43A4237BC7971884C50C0EB@gmail.com","subject":"Re: Bug: Recursive submodules fail when the repo path contains spaces","fromName":"Heiko Voigt","fromEmail":"hvoigt@hvoigt.net","sentAt":"2012-07-28T16:21:32Z","receivedAt":"2012-07-28T16:21:32Z","isPatch":false,"sender":{"key":"hvoigt@hvoigt.net","avatar":"https://avatars.githubusercontent.com/u/184958?v=4"},"body":"On Tue, Jul 24, 2012 at 01:33:44PM -0700, Justin Spahr-Summers wrote:\n> Here's some real output, with a couple specific names removed, starting from the root of the top-level repository (where External/twui is a submodule):\n> \n> $ cd External/twui\n> $ git submodule add git://github.com/petejkim/expecta.git TwUITests/expecta\n> Cloning into 'TwUITests/expecta'...\n> remote: Counting objects: 988, done.\n> remote: Compressing objects: 100% (404/404), done.\n> remote: Total 988 (delta 680), reused 842 (delta 535)\n> Receiving objects: 100% (988/988), 156.30 KiB, done.\n> Resolving deltas: 100% (680/680), done.\n> fatal: Not a git repository: ../../../../../../../../Volumes/drive name with spaces/Users/justin/Documents/Programming/project name with spaces/.git/modules/External/twui/modules/TwUITests/expecta\n\nIs this a copy&paste artefact or is the path in the error truncated?\n\nCheers Heiko\n"},{"id":"196035","messageId":"AE66EC4E32FD431287B84B3A0DBEEE3B@gmail.com","threadId":"31086","inReplyTo":"20120728162132.GC98893@book.hvoigt.net","subject":"Re: Bug: Recursive submodules fail when the repo path contains spaces","fromName":"Justin Spahr-Summers","fromEmail":"justin.spahrsummers@gmail.com","sentAt":"2012-07-28T17:53:45Z","receivedAt":"2012-07-28T17:53:45Z","isPatch":false,"sender":{"key":"justin.spahrsummers@gmail.com","avatar":"https://gravatar.com/avatar/2b9de55d3726992f28e8c88424641352911c174cb6561a125feb733affd598ba?d=mp&s=160"},"body":"On Saturday, 28. July 2012 at 09:21, Heiko Voigt wrote:\n> On Tue, Jul 24, 2012 at 01:33:44PM -0700, Justin Spahr-Summers wrote:\n> > Here's some real output, with a couple specific names removed, starting from the root of the top-level repository (where External/twui is a submodule):\n> > \n> > $ cd External/twui\n> > $ git submodule add git://github.com/petejkim/expecta.git (http://github.com/petejkim/expecta.git) TwUITests/expecta\n> > Cloning into 'TwUITests/expecta'...\n> > remote: Counting objects: 988, done.\n> > remote: Compressing objects: 100% (404/404), done.\n> > remote: Total 988 (delta 680), reused 842 (delta 535)\n> > Receiving objects: 100% (988/988), 156.30 KiB, done.\n> > Resolving deltas: 100% (680/680), done.\n> > fatal: Not a git repository: ../../../../../../../../Volumes/drive name with spaces/Users/justin/Documents/Programming/project name with spaces/.git/modules/External/twui/modules/TwUITests/expecta\n> \n> \n> \n> Is this a copy&paste artefact or is the path in the error truncated? \nThere's apparently some weird wrapping from my email client (the git error is on a single line in the terminal), but there is no truncation. That's the full path. Thanks for clarifying, though.\n"},{"id":"196071","messageId":"CABURp0rM_zkA0Hb=kkJcEeqWBX0qgRqH-zviW8ofp-qQqkW6uw@mail.gmail.com","threadId":"31086","inReplyTo":"9ADC1C4EF43A4237BC7971884C50C0EB@gmail.com","subject":"Re: Bug: Recursive submodules fail when the repo path contains spaces","fromName":"Phil Hord","fromEmail":"phil.hord@gmail.com","sentAt":"2012-07-29T18:31:38Z","receivedAt":"2012-07-29T18:31:38Z","isPatch":false,"sender":{"key":"phil.hord@gmail.com","avatar":"https://avatars.githubusercontent.com/u/123908?v=4"},"body":"On Tue, Jul 24, 2012 at 4:33 PM, Justin Spahr-Summers\n<justin.spahrsummers@gmail.com> wrote:\n> On Tuesday, 24. July 2012 at 13:26, Junio C Hamano wrote:\n>> Jens Lehmann <Jens.Lehmann@web.de (http://web.de)> writes:\n>>\n>> > Am 24.07.2012 21:01, schrieb Justin Spahr-Summers:\n>> > > This occurs on Mac OS X 10.7.4, on git versions 1.7.10.2 (Apple Git-33) and 1.7.11.3.\n>> > >\n>> > > Steps:\n>> > > 1. Create or clone a repository to an absolute path that contains spaces.\n>> > > 2. Add a submodule to the repository, if it does not already have one.\n>> > > 3. Within that submodule, attempt to add another submodule.\n>> > >\n>> > > 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.\n>> > >\n>> > > 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.\n>> >\n>> > Hmm, I don't understand how that is different from what t7407 does, it uses\n>> > \"git submodule update --init --recursive\" in to populate recursive submodules\n>> > in a freshly cloned repository whose path contains a space (in the trash\n>> > directory name) in test number 8.\n>>\n>>\n>>\n>> I can see one codepath that would behave incorrectly, especially if\n>> the submodule path relative to the superproject has whitespaces in\n>> it. In module_clone(), you have:\n>>\n>> # We already are at the root of the work tree but cd_to_toplevel will\n>> # resolve any symlinks that might be present in $PWD\n>> a=$(cd_to_toplevel && cd \"$gitdir\" && pwd)/\n>> b=$(cd_to_toplevel && cd \"$sm_path\" && pwd)/\n>> ...\n>> # Turn each leading \"*/\" component into \"../\"\n>> rel=$(echo $b | sed -e 's|[^/][^/]*|..|g')\n>> echo \"gitdir: $rel/$a\" >\"$sm_path/.git\"\n>>\n>> I _think_ $sm_path is computed correctly by the codeflow leading to\n>> this place, and $b is also computed correctly, but notice the lack\n>> of quoting around $b when you echo it? It will be split at $IFS, so\n>> if b='/Program Files/My Stupidity/', the sed script will see a\n>> single SP between My and Stupidity, which is different from what you\n>> wanted to feed, I presume.\n>>\n>> Having said that, I do not think git-submodule is prepared to take\n>> paths with path-unsafe characters in it, given that many part of it\n>> has loops like \"while read mode sha1 stage sm_path\" that reads from\n>> ls-files/ls-tree output without -z (which means it cannot handle\n>> pathnames with LF in them).\n>>\n>> My recommendation at this point (i.e. not a long term) for people\n>> with problems Justin saw is \"Don't do it then\".\n>\n> I appreciate the debugging work. Unfortunately, none of the relative submodule paths have had whitespace in them, so I'm not sure that's the issue.\n>\n> Here's some real output, with a couple specific names removed, starting from the root of the top-level repository (where External/twui is a submodule):\n>\n> $ cd External/twui\n> $ git submodule add git://github.com/petejkim/expecta.git TwUITests/expecta\n> Cloning into 'TwUITests/expecta'...\n> remote: Counting objects: 988, done.\n> remote: Compressing objects: 100% (404/404), done.\n> remote: Total 988 (delta 680), reused 842 (delta 535)\n> Receiving objects: 100% (988/988), 156.30 KiB, done.\n> Resolving deltas: 100% (680/680), done.\n> fatal: Not a git repository: ../../../../../../../../Volumes/drive name with spaces/Users/justin/Documents/Programming/project name with spaces/.git/modules/External/twui/modules/TwUITests/expecta\n\nI saw something similar before but I was unable to reproduce the\nconditions.  In my case, my superproject was cloned with an earlier\nversion of git and some new submodule behaviors seemed to cause me\nproblems.\n\nIs \"project name with spaces\" a freshly cloned project also using,\nsay, 1.7.11.3?\n\nI am not able to reproduce the problem here on Linux using your same\nexample command.\n\nPhil\n"},{"id":"196074","messageId":"FE466454ECCE48A19472B85D1C92E9E2@gmail.com","threadId":"31086","inReplyTo":"CABURp0rM_zkA0Hb=kkJcEeqWBX0qgRqH-zviW8ofp-qQqkW6uw@mail.gmail.com","subject":"Re: Bug: Recursive submodules fail when the repo path contains spaces","fromName":"Justin Spahr-Summers","fromEmail":"justin.spahrsummers@gmail.com","sentAt":"2012-07-29T19:30:14Z","receivedAt":"2012-07-29T19:30:14Z","isPatch":false,"sender":{"key":"justin.spahrsummers@gmail.com","avatar":"https://gravatar.com/avatar/2b9de55d3726992f28e8c88424641352911c174cb6561a125feb733affd598ba?d=mp&s=160"},"body":"On Sunday, 29. July 2012 at 11:31, Phil Hord wrote:\n> On Tue, Jul 24, 2012 at 4:33 PM, Justin Spahr-Summers\n> <justin.spahrsummers@gmail.com (mailto:justin.spahrsummers@gmail.com)> wrote:\n> > On Tuesday, 24. July 2012 at 13:26, Junio C Hamano wrote:\n> > > Jens Lehmann <Jens.Lehmann@web.de (http://web.de)> writes:\n> > > \n> > > > Am 24.07.2012 21:01, schrieb Justin Spahr-Summers:\n> > > > > This occurs on Mac OS X 10.7.4, on git versions 1.7.10.2 (Apple Git-33) and 1.7.11.3.\n> > > > > \n> > > > > Steps:\n> > > > > 1. Create or clone a repository to an absolute path that contains spaces.\n> > > > > 2. Add a submodule to the repository, if it does not already have one.\n> > > > > 3. Within that submodule, attempt to add another submodule.\n> > > > > \n> > > > > 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.\n> > > > > \n> > > > > 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.\n> > > > \n> > > > Hmm, I don't understand how that is different from what t7407 does, it uses\n> > > > \"git submodule update --init --recursive\" in to populate recursive submodules\n> > > > in a freshly cloned repository whose path contains a space (in the trash\n> > > > directory name) in test number 8.\n> > > \n> > > \n> > > \n> > > \n> > > \n> > > I can see one codepath that would behave incorrectly, especially if\n> > > the submodule path relative to the superproject has whitespaces in\n> > > it. In module_clone(), you have:\n> > > \n> > > # We already are at the root of the work tree but cd_to_toplevel will\n> > > # resolve any symlinks that might be present in $PWD\n> > > a=$(cd_to_toplevel && cd \"$gitdir\" && pwd)/\n> > > b=$(cd_to_toplevel && cd \"$sm_path\" && pwd)/\n> > > ...\n> > > # Turn each leading \"*/\" component into \"../\"\n> > > rel=$(echo $b | sed -e 's|[^/][^/]*|..|g')\n> > > echo \"gitdir: $rel/$a\" >\"$sm_path/.git\"\n> > > \n> > > I _think_ $sm_path is computed correctly by the codeflow leading to\n> > > this place, and $b is also computed correctly, but notice the lack\n> > > of quoting around $b when you echo it? It will be split at $IFS, so\n> > > if b='/Program Files/My Stupidity/', the sed script will see a\n> > > single SP between My and Stupidity, which is different from what you\n> > > wanted to feed, I presume.\n> > > \n> > > Having said that, I do not think git-submodule is prepared to take\n> > > paths with path-unsafe characters in it, given that many part of it\n> > > has loops like \"while read mode sha1 stage sm_path\" that reads from\n> > > ls-files/ls-tree output without -z (which means it cannot handle\n> > > pathnames with LF in them).\n> > > \n> > > My recommendation at this point (i.e. not a long term) for people\n> > > with problems Justin saw is \"Don't do it then\".\n> > \n> > \n> > \n> > I appreciate the debugging work. Unfortunately, none of the relative submodule paths have had whitespace in them, so I'm not sure that's the issue.\n> > \n> > Here's some real output, with a couple specific names removed, starting from the root of the top-level repository (where External/twui is a submodule):\n> > \n> > $ cd External/twui\n> > $ git submodule add git://github.com/petejkim/expecta.git (http://github.com/petejkim/expecta.git) TwUITests/expecta\n> > Cloning into 'TwUITests/expecta'...\n> > remote: Counting objects: 988, done.\n> > remote: Compressing objects: 100% (404/404), done.\n> > remote: Total 988 (delta 680), reused 842 (delta 535)\n> > Receiving objects: 100% (988/988), 156.30 KiB, done.\n> > Resolving deltas: 100% (680/680), done.\n> > fatal: Not a git repository: ../../../../../../../../Volumes/drive name with spaces/Users/justin/Documents/Programming/project name with spaces/.git/modules/External/twui/modules/TwUITests/expecta\n> \n> \n> \n> I saw something similar before but I was unable to reproduce the\n> conditions. In my case, my superproject was cloned with an earlier\n> version of git and some new submodule behaviors seemed to cause me\n> problems.\n> \n> Is \"project name with spaces\" a freshly cloned project also using,\n> say, 1.7.11.3?\n> \n> I am not able to reproduce the problem here on Linux using your same\n> example command.\n\nHmm, you're right. After further investigation, this actually looks like a weird issue with soft links. Here's some exact output (with spacing only for clarity), using a public test repository at https://github.com/jspahrsummers/recursive-submodules-test:\n\njustin:~/ $ ls -l HDD\nlrwxr-xr-x 1 justin staff 34 5 Jan 2012 HDD -> /Volumes/fadelah data/Users/justin\n\njustin:~/ $ cd HDD\njustin:HDD/ $ pwd\n/Users/justin/HDD\n\njustin:HDD/ $ git clone git@github.com:jspahrsummers/recursive-submodules-test.git\nCloning into 'recursive-submodules-test'...\nremote: Counting objects: 6, done.\nremote: Compressing objects: 100% (4/4), done.\nremote: Total 6 (delta 1), reused 5 (delta 0)\nReceiving objects: 100% (6/6), done.\nResolving deltas: 100% (1/1), done.\n\njustin:HDD/ $ cd recursive-submodules-test\njustin:recursive-submodules-test/ (git)-[master] $ git submodule update --init --recursive\nSubmodule 'objective-git' (git://github.com/libgit2/objective-git.git) registered for path 'objective-git'\nCloning into 'objective-git'...\nremote: Counting objects: 2990, done.\nremote: Compressing objects: 100% (981/981), done.\nremote: Total 2990 (delta 2138), reused 2751 (delta 1915)\nReceiving objects: 100% (2990/2990), 7.20 MiB | 1.21 MiB/s, done.\nResolving deltas: 100% (2138/2138), done.\nSubmodule path 'objective-git': checked out '58d0dc708876038e0db34447a176614956f3f480'\nSubmodule 'libgit2' (git://github.com/libgit2/libgit2.git) registered for path 'libgit2'\nCloning into 'libgit2'...\nremote: Counting objects: 19703, done.\nremote: Compressing objects: 100% (5743/5743), done.\nremote: Total 19703 (delta 14448), reused 18712 (delta 13585)\nReceiving objects: 100% (19703/19703), 5.87 MiB | 498 KiB/s, done.\nResolving deltas: 100% (14448/14448), done.\nfatal: Not a git repository: ../../../../../../Volumes/fadelah data/Users/justin/recursive-submodules-test/.git/modules/objective-git/modules/libgit2\nFailed to recurse into submodule path 'objective-git'\n"},{"id":"196078","messageId":"CABURp0oHchc8KuwE+AxwzygLSi30+qiyqX=tfj9_rQrjBgO5AA@mail.gmail.com","threadId":"31086","inReplyTo":"FE466454ECCE48A19472B85D1C92E9E2@gmail.com","subject":"Re: Bug: Recursive submodules fail when the repo path contains spaces","fromName":"Phil Hord","fromEmail":"phil.hord@gmail.com","sentAt":"2012-07-29T21:10:51Z","receivedAt":"2012-07-29T21:10:51Z","isPatch":false,"sender":{"key":"phil.hord@gmail.com","avatar":"https://avatars.githubusercontent.com/u/123908?v=4"},"body":"On Sun, Jul 29, 2012 at 3:30 PM, Justin Spahr-Summers\n<justin.spahrsummers@gmail.com> wrote:\n> Hmm, you're right. After further investigation, this actually looks like a weird issue with soft links. Here's some exact output (with spacing only for clarity), using a public test repository at https://github.com/jspahrsummers/recursive-submodules-test:\n\nI can reproduce the problem now on 1.7.10.3.  However the problem goes\naway in 1.7.12 since it was fixed in\n\n6eafa6d096ce6b0ae20e4c0fbb248958559daf64\nAuthor: Jens Lehmann <Jens.Lehmann@web.de>\nDate:   Thu Jul 12 19:45:32 2012 +0200\nSubject: submodules: don't stumble over symbolic links when cloning recursively\n\nRegards,\nPhil\n"},{"id":"196079","messageId":"72E23CD93B354FB28AFD12DDA7303016@gmail.com","threadId":"31086","inReplyTo":"CABURp0oHchc8KuwE+AxwzygLSi30+qiyqX=tfj9_rQrjBgO5AA@mail.gmail.com","subject":"Re: Bug: Recursive submodules fail when the repo path contains spaces","fromName":"Justin Spahr-Summers","fromEmail":"justin.spahrsummers@gmail.com","sentAt":"2012-07-29T21:13:55Z","receivedAt":"2012-07-29T21:13:55Z","isPatch":false,"sender":{"key":"justin.spahrsummers@gmail.com","avatar":"https://gravatar.com/avatar/2b9de55d3726992f28e8c88424641352911c174cb6561a125feb733affd598ba?d=mp&s=160"},"body":"On Sunday, 29. July 2012 at 14:10, Phil Hord wrote:\n> On Sun, Jul 29, 2012 at 3:30 PM, Justin Spahr-Summers\n> <justin.spahrsummers@gmail.com (mailto:justin.spahrsummers@gmail.com)> wrote:\n> > Hmm, you're right. After further investigation, this actually looks like a weird issue with soft links. Here's some exact output (with spacing only for clarity), using a public test repository at https://github.com/jspahrsummers/recursive-submodules-test:\n> \n> \n> \n> I can reproduce the problem now on 1.7.10.3. However the problem goes\n> away in 1.7.12 since it was fixed in\n> \n> 6eafa6d096ce6b0ae20e4c0fbb248958559daf64\n> Author: Jens Lehmann <Jens.Lehmann@web.de (http://web.de)>\n> Date: Thu Jul 12 19:45:32 2012 +0200\n> Subject: submodules: don't stumble over symbolic links when cloning recursively\n> \n> Regards,\n> Phil\n\nAh, good to know. Thanks, everyone, for the help. \n"}]}