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

[Jens Lehmann <Jens.Lehmann@web.de>]

Am 17.04.2013 01:52, schrieb Junio C Hamano:
>> * jk/submodule-subdirectory-ok (2013-04-10) 2 commits
>>  - 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.
>>
>>  Waiting for comments.
> 
> Any submodule users wants to weigh in?  The code looked fine, but I
> do not heavily use it (and the repository with a submodule I have, I
> do not have a "subdirectory" ;-, so I am a bad guinea pig).

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

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

So this is a good start, but it looks like there is some work left
to do before this can hit master.