On Mon, Oct 1, 2018 at 8:45 AM Antonio Ospite <ao2@xxxxxx> wrote: > > On Thu, 27 Sep 2018 11:00:52 -0700 > Stefan Beller <sbeller@xxxxxxxxxx> wrote: > > > On Thu, Sep 27, 2018 at 7:44 AM Antonio Ospite <ao2@xxxxxx> wrote: > [...] > > > OK, so the plan for v6 is: > > > > > > - avoid the corruption issues spotted by Gábor by removing the call > > > to repo_read_gitmodules in builtin/grep.c (this still does not fix > > > the potential problem with nested submodules). > > > > > Actually that is not enough to fix the inconsistent access to the > object store: the functions is_submodule_active() and > repo_submodule_init() too end up calling config_from_gitmodules() and > need protecting as well, so I am going to put them under the git read > lock and leave repo_read_gitmodules() in place for now. > > > I am asking because the whole point of this patchset is to *enable* the > use of submodules without .gitmodules in the working tree of the > superproject. :) I was imprecise and meant to s/.gitmodules/mechanism to configure the name <-> path mapping/ In this series, the .gitmodules may not be present in the working tree, but it is still there in the repo. Later we may want to rename that file or put it into a magic branch, and I'd still find it a good idea. What I find a bad idea is to have only a gitlink and a repo put into that path and expect that it magically works as then it is not a submodule, but some "halfway there thing". We need to have an explicit "yes this is a submodule" statement, (which currently comes from the .gitmodules file in the working tree), and I am not attached to where it comes from, but that it exists.
