Re: [PATCH v5 1/4] implement submodule config API for lookup of .gitmodules values

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Am 09.07.2015 um 17:49 schrieb Jeff King:
On Thu, Jul 09, 2015 at 02:09:01PM +0200, Heiko Voigt wrote:

Instead of test-submodule-config.c to test this new module, it could
be useful to implement these as extensions to rev-parse:

     git rev-parse --submodule-name [<ref>:]<path>
     git rev-parse --submodule-path [<ref>:]<name>
     git rev-parse --submodule-url [<ref>:]<name>
     git rev-parse --submodule-ignore [<ref>:]<name>
     git rev-parse --submodule-recurse [<ref>:]<name>

Has this already been considered and rejected for some reason?

No that has not been considered. But I am open to it if others agree
that this is a sensible thing to do. We should be able to adapt the
existing tests right?

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.
--
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



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]