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

[Junio C Hamano <gitster@pobox.com>]

Peter Kästle <peter.kaestle@nokia.com> writes:

> Originally, without applying the v3 series, I can see those testcases:
>
> 1) not-init, not-cloned: 'status should initially be "missing"'
> 2) init, not-cloned: MISSING
> 3) not-init, cloned: MISSING
> 4) init, cloned: 'status should be "up-to-date" after update'
> 4.1) + modified: 'status should be "modified" after submodule commit'
> 4.2) + modified, committed: 'status should be "up-to-date" after update'
>
> My patch v3 series adds a testcase for 2).

That's good.

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

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