Re: "What's cooking" between #05 and #06

[John Keeping <john@keeping.me.uk>]

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.