Jens Lehmann [off-list ref] writes:
quoted
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"?
On Thu, Jul 09, 2015 at 01:00:10PM -0700, Junio C Hamano wrote:
Jens Lehmann [off-list ref] writes:
quoted
quoted
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