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