From: Peter Kästle Date: Mon, 27 Jan 2020 08:52:21 GMT Subject: Re: [PATCH v2] Fix status of initialized but not cloned submodules Message-ID: <41a835a3-3809-eda8-fb3c-30fe9fac1a24@nokia.com> In-Reply-To: Hi, On 24.01.20 18:16, Junio C Hamano wrote: > Peter Kästle 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;