Re: [PATCH v2] Fix status of initialized but not cloned submodules

["Peter Kästle" <peter.kaestle@nokia.com>]

Hi,

On 24.01.20 18:16, Junio C Hamano wrote:
> Peter Kästle <peter.kaestle@nokia.com> writes:

[...]

>> Is 3) even a possible use-case?
> 
> That would be somebody who is about to add a submodule to an
> existing project, right?  You have a top-level project, you need
> somebody else's project as its submodule or you need to use a
> library in your top-level project and you develop the library
> yourself, but want to keep that library part separate from its first
> user which is your top-level project.  So in the working tree of a
> top-level project you either "git init lib/" and start the submodule
> project right there, or "git clone $URL_of_upstream_of_lib lib/",
> and then plan to do "git submodule add lib", but haven't done so
> yet.  .gitmodules does not know about it, but the directory is
> already populated and is a valid repository.

You are right, this is a possible scenario for 3).  However the question 
about how the outer git repo should behave is still open to me.  I mean, 
the outer git repo should treat the inner one as standard file structure 
and not as a submodule until the user explicitly calls the "git 
submodule add" command.  And thus "git submodule status" should 
completely skip it.  Calling "git status" in the outer repo should list 
the inner one as "untracked" or?
At least this is, what I would expect.
So from my point of view the only test for 3) we could do is something 
like this:
mkdir innerfoo &&
(cd innerfoo &&
git init) &&
test_must_fail git submodule status | grep "innerfoo"


>> Besides that, I think testcases for man git-submodule's description of
>> status on merge conflicts are missing (...[prefix] U if the submodule
>> has merge conflicts).
> 
> Nice to know.  Thanks.

Maybe I'll have spare time next weekend to create some.  Not to promise 
anything, but sounds like fun.

-- 
best regards,
--peter;