Hi,
On 24.01.20 18:16, Junio C Hamano wrote:
Peter Kästle <peter.kaestle@xxxxxxxxx> 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;
