On Thu, Jul 09, 2015 at 01:00:10PM -0700, Junio C Hamano wrote: > Jens Lehmann <Jens.Lehmann@xxxxxx> writes: > > >> How does git-submodule access this information? It looks like it just > >> hits "git config -f .gitmodules" directly. Perhaps whatever interface is > >> designed should be suitable for its use here (and if there really is no > >> more interesting interface needed, then why is "git config" not good > >> enough for other callers?). > > > > The git-submodule script doesn't need this and is fine using plain old > > "git config", as by the time it is run the .gitmodules file is already > > updated in the work tree. Heiko's series is about adding infrastructure > > to allow builtins like checkout and friends to access the configuration > > values from the .gitmodules file of the to-be-checked-out commit when > > run with "--recurse-submodules". And yes, if we want to expose this > > functionality to users or scripts some day "git config" looks like the > > best place to do that to me too. > > Did you mean "git submodule config"? I think he actually meant "git config" and that is already implemented. When I implemented the infrastructure to read configurations from blobs, Peff extended it so it will be exposed via the config command line. E.g. you can do: git config --blob HEAD^^^:.gitmodules <value> to get .gitmodules configurations from the history, so that is already implemented. And for reading .gitmodules values we probably do not need more, since calling git from scripting we always have new invocations of processes anyway and that would throw away the cache I am implementing. Reading such values via config from scripts is also more flexible since it supports arbitrary values and my cache only specific values needed by the builtins that use it. My submodule config cache infrastructure is directed for C-code wanting to query submodule values. So e.g. when "git checkout" wants to know about values but the ".gitmodules" file that is in charge, but has not been checked out yet. We also need this for fetch which will actually need values from more than one revision, since we might need to merge configurations when fetching multiple branches. Fetch also needs information about URLs for new submodules that appear in branches, when auto clone is switched on. That means to support the "I want to go on an airplane get me everything I might need" use-case. Cheers Heiko -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html