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

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 24, 2020, 17:16 UTC
Message-ID: <xmqqblqs3hbv.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <9192695a-0b3f-d166-7efa-84f57e091c2c@nokia.com>

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

Show 10 quoted lines

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