> Well, submodule-config.c has its implementation and another caller, > which technically is outside submodule.c ;-) i.e. there is a typo in my commit message. I meant to say submodule-config.c > repo_read_gitmodules > has two more callers in unpack-trees.c these days, so perhaps we can > do without this last paragraph. Gah, looking at that code, did we have any reason to rush that series? c.f. https://public-inbox.org/git/20170811171811.GC1472@xxxxxxxxxxxxxxx/ On Sat, Oct 6, 2018 at 5:33 PM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > Stefan Beller <sbeller@xxxxxxxxxx> writes: > > > After ff6f1f564c4 (submodule-config: lazy-load a repository's .gitmodules > > file, 2017-08-03) this is no longer necessary, but that commit did not > > cleanup the whole tree, but just show cased the new way how to deal with > > submodules in ls-files. > > The log message of the above one singles out "grep" as a special > case and explalins why it did not touch, by the way. You probably > need to explain the reason why "this is no longer necessary" a bit > better than the above---as it stands, it is "ff6f1f564c4 said it > still is necessary, I say it is not". That is true. For grep, the reason seems to be, that we check is_submodule_active based off the index, i.e. using module = submodule_from_path(repo, &null_oid, path); as the deciding factor, which falls in line with lazyloading. However the use of the specialized gitmodules_config_oid in grep is also guarded by the same commit ff6f1f564c4. Going back to the use case of unpack-trees.c, I think that we need to keep it there as alternatives seem to be more complicated. So I guess I'll just resend with a better commit message. Thanks, Stefan
