Am 17.04.2013 01:52, schrieb Junio C Hamano: >> * jk/submodule-subdirectory-ok (2013-04-10) 2 commits >> - submodule: drop the top-level requirement >> - rev-parse: add --prefix option >> >> Allow various subcommands of "git submodule" to be run not from the >> top of the working tree of the superproject. >> >> Waiting for comments. > > Any submodule users wants to weigh in? The code looked fine, but I > do not heavily use it (and the repository with a submodule I have, I > do not have a "subdirectory" ;-, so I am a bad guinea pig). I like it, as it gets rid of the top-level requirement. But from my testing it looks like we're not quite there yet. 'summary' and 'status' behave as if they were run in the toplevel directory, while a "git status" shows all filenames relative to the current directory. Me thinks 'summary' and 'status' (and all other submodule commands) should behave like status and print relative paths too. I'm not really sure yet how $sm_path should behave for 'foreach', but I suspect having it relative to the current directory would be the way to go (which it currently isn't). When "submodule add" is run with a relative path it is relative to the top-level directory, which I find confusing (and won't play well with shell completion). 'deinit .' doesn't deinit submodules above the current directory (but prints the path relative to top-level) while 'init' will initialize all submodules known to the superproject. So this is a good start, but it looks like there is some work left to do before this can hit master. -- 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