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

From: John Keeping <john@keeping.me.uk>
Date: Apr 18, 2013, 08:49 UTC
Message-ID: <20130418084923.GT2278@serenity.lan>
In-Reply-To: <516F1333.5070804@web.de>

On Wed, Apr 17, 2013 at 11:25:07PM +0200, Jens Lehmann wrote:

Show 14 quoted lines

> 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.