On Thu, May 30, 2013 at 09:23:40PM +0200, Jens Lehmann wrote: > Am 30.05.2013 01:58, schrieb Junio C Hamano: > > * jk/submodule-subdirectory-ok (2013-04-24) 3 commits > > (merged to 'next' on 2013-04-24 at 6306b29) > > + submodule: fix quoting in relative_path() > > (merged to 'next' on 2013-04-22 at f211e25) > > + 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. > > The summary and status commands are looking good in this version > (they are now showing the submodule directory paths relative to > the current directory). Apart from that my other remarks from > gmane $221575 still seem to apply. And this series has only tests > for status, summary and add (and that just with an absolute URL), > I'd rather like to see a test for each submodule command (and a > relative add to) to document the desired behavior. To summarize what I think are the outstanding issues from your email: * Should '$sm_path' be relative in "submodule foreach"? * "submodule add" with a relative path * "submodule init" initializes all submodules * Tests The current version does make '$sm_path' relative in "submodule foreach", although it's hard to spot because we have to leave doing so until right before the "eval". I'm not sure what you mean about "submodule add" - the new version treats the "path" argument as relative (providing it is not an absolute path). The "repository" argument is not changed by running from a subdirectory but I think that's correct since it is documented as being relative to the superproject's origin repository. "submodule init" is behaving in the same way as "deinit" - if you say "submodule init ." then it will only initialize submodules below the current directory. The difference is that "deinit" dies if it is not given any arguments whereas "init" will initialize everything from the top level down. I'm not sure whether to change this; given the direction "git add -u" is heading in for 2.0 I think the current behaviour is the most consistent with the rest of Git. > But I'm not sure if it's better to have another iteration of this > series or to address the open issues a follow-up series. Having > status, summary and add - at least with absolute URLs - lose the > toplevel requirement is already a huge improvement IMO. Opinions? I think the only thing outstanding is tests. I'm happy to add those as a follow-up or in a re-roll. -- 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