Peter Kästle <peter.kaestle@xxxxxxxxx> 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.
