On Wed, Apr 17, 2013 at 11:25:07PM +0200, Jens Lehmann wrote: > 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).
This confused me for a bit because I was sure I handled this, but I see I missed relative submodules URLs. So the path at which to put the submodule is correct, but the path from which to clone is not. > '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. I can't see how this happens. 'init' uses module_list which has been updated to handle relative paths. So I expect 'git submodule init .' to work correctly here. I would expect either of them to act on all submodules when given no extra arguments. > So this is a good start, but it looks like there is some work left > to do before this can hit master. Thanks for the feedback. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
