mirrors/git
1
0
Fork 0
mirror of https://github.com/git/git.git synced 2024-10-30 05:47:53 +01:00
Code Activity
git/submodule-config.h

71 lines
2.3 KiB
C
Raw Normal View History

submodule: implement a config API for lookup of .gitmodules values In a superproject some commands need to interact with submodules. They need to query values from the .gitmodules file either from the worktree of from certain revisions. At the moment this is quite hard since a caller would need to read the .gitmodules file from the history and then parse the values. We want to provide an API for this so we have one place to get values from .gitmodules from any revision (including the worktree). The API is realized as a cache which allows us to lazily read .gitmodules configurations by commit into a runtime cache which can then be used to easily lookup values from it. Currently only the values for path or name are stored but it can be extended for any value needed. It is expected that .gitmodules files do not change often between commits. Thats why we lookup the .gitmodules sha1 from a commit and then either lookup an already parsed configuration or parse and cache an unknown one for each sha1. The cache is lazily build on demand for each requested commit. This cache can be used for all purposes which need knowledge about submodule configurations. Example use cases are: * Recursive submodule checkout needs to lookup a submodule name from its path when a submodule first appears. This needs be done before this configuration exists in the worktree. * The implementation of submodule support for 'git archive' needs to lookup the submodule name to generate the archive when given a revision that is not checked out. * 'git fetch' when given the --recurse-submodules=on-demand option (or configuration) needs to lookup submodule names by path from the database rather than reading from the worktree. For new submodule it needs to lookup the name from its path to allow cloning new submodules into the .git folder so they can be checked out without any network interaction when the user does a checkout of that revision. Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net> Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-08-18 02:21:57 +02:00
#ifndef SUBMODULE_CONFIG_CACHE_H
#define SUBMODULE_CONFIG_CACHE_H
submodule-config: convert structures to object_id Convert struct submodule and struct parse_config_parameter to use struct object_id. Adjust the functions which take members of these structures as arguments to also use struct object_id. Include cache.h into submodule-config.h to make struct object_id visible. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-02 02:25:42 +02:00
#include "cache.h"
config: move config_from_gitmodules to submodule-config.c The .gitmodules file is not meant as a place to store arbitrary configuration to distribute with the repository. Move config_from_gitmodules() out of config.c and into submodule-config.c to make it even clearer that it is not a mechanism to retrieve arbitrary configuration from the .gitmodules file. Signed-off-by: Antonio Ospite <ao2@ao2.it> Acked-by: Brandon Williams <bmwill@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-26 12:47:05 +02:00
#include "config.h"
submodule: implement a config API for lookup of .gitmodules values In a superproject some commands need to interact with submodules. They need to query values from the .gitmodules file either from the worktree of from certain revisions. At the moment this is quite hard since a caller would need to read the .gitmodules file from the history and then parse the values. We want to provide an API for this so we have one place to get values from .gitmodules from any revision (including the worktree). The API is realized as a cache which allows us to lazily read .gitmodules configurations by commit into a runtime cache which can then be used to easily lookup values from it. Currently only the values for path or name are stored but it can be extended for any value needed. It is expected that .gitmodules files do not change often between commits. Thats why we lookup the .gitmodules sha1 from a commit and then either lookup an already parsed configuration or parse and cache an unknown one for each sha1. The cache is lazily build on demand for each requested commit. This cache can be used for all purposes which need knowledge about submodule configurations. Example use cases are: * Recursive submodule checkout needs to lookup a submodule name from its path when a submodule first appears. This needs be done before this configuration exists in the worktree. * The implementation of submodule support for 'git archive' needs to lookup the submodule name to generate the archive when given a revision that is not checked out. * 'git fetch' when given the --recurse-submodules=on-demand option (or configuration) needs to lookup submodule names by path from the database rather than reading from the worktree. For new submodule it needs to lookup the name from its path to allow cloning new submodules into the .git folder so they can be checked out without any network interaction when the user does a checkout of that revision. Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net> Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-08-18 02:21:57 +02:00
#include "hashmap.h"
submodule-config: keep update strategy around Currently submodule.<name>.update is only handled by git-submodule.sh. C code will start to need to make use of that value as more of the functionality of git-submodule.sh moves into library code in C. Add the update field to 'struct submodule' and populate it so it can be read as sm->update or from sm->update_command. Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-03-01 03:07:11 +01:00
#include "submodule.h"
submodule: implement a config API for lookup of .gitmodules values In a superproject some commands need to interact with submodules. They need to query values from the .gitmodules file either from the worktree of from certain revisions. At the moment this is quite hard since a caller would need to read the .gitmodules file from the history and then parse the values. We want to provide an API for this so we have one place to get values from .gitmodules from any revision (including the worktree). The API is realized as a cache which allows us to lazily read .gitmodules configurations by commit into a runtime cache which can then be used to easily lookup values from it. Currently only the values for path or name are stored but it can be extended for any value needed. It is expected that .gitmodules files do not change often between commits. Thats why we lookup the .gitmodules sha1 from a commit and then either lookup an already parsed configuration or parse and cache an unknown one for each sha1. The cache is lazily build on demand for each requested commit. This cache can be used for all purposes which need knowledge about submodule configurations. Example use cases are: * Recursive submodule checkout needs to lookup a submodule name from its path when a submodule first appears. This needs be done before this configuration exists in the worktree. * The implementation of submodule support for 'git archive' needs to lookup the submodule name to generate the archive when given a revision that is not checked out. * 'git fetch' when given the --recurse-submodules=on-demand option (or configuration) needs to lookup submodule names by path from the database rather than reading from the worktree. For new submodule it needs to lookup the name from its path to allow cloning new submodules into the .git folder so they can be checked out without any network interaction when the user does a checkout of that revision. Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net> Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-08-18 02:21:57 +02:00
#include "strbuf.h"
/*
* Submodule entry containing the information about a certain submodule
* in a certain revision.
*/
struct submodule {
const char *path;
const char *name;
const char *url;
int fetch_recurse;
const char *ignore;
submodule-config: keep configured branch around The branch field will be used in a later patch by `submodule update`. Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-29 02:44:07 +02:00
const char *branch;
submodule-config: keep update strategy around Currently submodule.<name>.update is only handled by git-submodule.sh. C code will start to need to make use of that value as more of the functionality of git-submodule.sh moves into library code in C. Add the update field to 'struct submodule' and populate it so it can be read as sm->update or from sm->update_command. Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-03-01 03:07:11 +01:00
struct submodule_update_strategy update_strategy;
submodule-config: convert structures to object_id Convert struct submodule and struct parse_config_parameter to use struct object_id. Adjust the functions which take members of these structures as arguments to also use struct object_id. Include cache.h into submodule-config.h to make struct object_id visible. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-02 02:25:42 +02:00
/* the object id of the responsible .gitmodules file */
struct object_id gitmodules_oid;
submodule-config: keep shallow recommendation around The shallow field will be used in a later patch by `submodule update`. To differentiate between the actual depth (which may be different), we name it `recommend_shallow` as the field in the .gitmodules file is only a recommendation by the project. Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-05-26 23:59:42 +02:00
int recommend_shallow;
submodule: implement a config API for lookup of .gitmodules values In a superproject some commands need to interact with submodules. They need to query values from the .gitmodules file either from the worktree of from certain revisions. At the moment this is quite hard since a caller would need to read the .gitmodules file from the history and then parse the values. We want to provide an API for this so we have one place to get values from .gitmodules from any revision (including the worktree). The API is realized as a cache which allows us to lazily read .gitmodules configurations by commit into a runtime cache which can then be used to easily lookup values from it. Currently only the values for path or name are stored but it can be extended for any value needed. It is expected that .gitmodules files do not change often between commits. Thats why we lookup the .gitmodules sha1 from a commit and then either lookup an already parsed configuration or parse and cache an unknown one for each sha1. The cache is lazily build on demand for each requested commit. This cache can be used for all purposes which need knowledge about submodule configurations. Example use cases are: * Recursive submodule checkout needs to lookup a submodule name from its path when a submodule first appears. This needs be done before this configuration exists in the worktree. * The implementation of submodule support for 'git archive' needs to lookup the submodule name to generate the archive when given a revision that is not checked out. * 'git fetch' when given the --recurse-submodules=on-demand option (or configuration) needs to lookup submodule names by path from the database rather than reading from the worktree. For new submodule it needs to lookup the name from its path to allow cloning new submodules into the .git folder so they can be checked out without any network interaction when the user does a checkout of that revision. Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net> Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-08-18 02:21:57 +02:00
};
implement fetching of moved submodules We store the changed submodules paths to calculate which submodule needs fetching. This does not work for moved submodules since their paths do not stay the same in case of a moved submodules. In case of new submodules we do not have a path in the current checkout, since they just appeared in this fetch. It is more general to collect the submodule names for changes instead of their paths to include the above cases. If we do not have a configuration for a gitlink we rely on constructing a default name from the path if a git repository can be found at its path. We skip non-configured gitlinks whose default name collides with a configured one. With the change described above we implement 'on-demand' fetching of changes in moved submodules. Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-10-16 15:58:27 +02:00
#define SUBMODULE_INIT { NULL, NULL, NULL, RECURSE_SUBMODULES_NONE, \
submodule-config: convert structures to object_id Convert struct submodule and struct parse_config_parameter to use struct object_id. Adjust the functions which take members of these structures as arguments to also use struct object_id. Include cache.h into submodule-config.h to make struct object_id visible. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-02 02:25:42 +02:00
NULL, NULL, SUBMODULE_UPDATE_STRATEGY_INIT, { { 0 } }, -1 };
implement fetching of moved submodules We store the changed submodules paths to calculate which submodule needs fetching. This does not work for moved submodules since their paths do not stay the same in case of a moved submodules. In case of new submodules we do not have a path in the current checkout, since they just appeared in this fetch. It is more general to collect the submodule names for changes instead of their paths to include the above cases. If we do not have a configuration for a gitlink we rely on constructing a default name from the path if a git repository can be found at its path. We skip non-configured gitlinks whose default name collides with a configured one. With the change described above we implement 'on-demand' fetching of changes in moved submodules. Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-10-16 15:58:27 +02:00
submodule-config: store the_submodule_cache in the_repository Refactor how 'the_submodule_cache' is handled so that it can be stored inside of a repository object. Also migrate 'the_submodule_cache' to be stored in 'the_repository'. Signed-off-by: Brandon Williams <bmwill@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-22 20:43:44 +02:00
struct submodule_cache;
struct repository;
extern void submodule_cache_free(struct submodule_cache *cache);
submodule: remove submodule.fetchjobs from submodule-config parsing The '.gitmodules' file should only contain information pertinent to configuring individual submodules (name to path mapping, URL where to obtain the submodule, etc.) while other configuration like the number of jobs to use when fetching submodules should be a part of the repository's config. Remove the 'submodule.fetchjobs' configuration option from the general submodule-config parsing and instead rely on using the 'config_from_gitmodules()' in order to maintain backwards compatibility with this config being placed in the '.gitmodules' file. Signed-off-by: Brandon Williams <bmwill@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-08-02 21:49:18 +02:00
extern int parse_submodule_fetchjobs(const char *var, const char *value);
update submodules: add submodule config parsing Similar to b33a15b08 (push: add recurseSubmodules config option, 2015-11-17) and 027771fcb1 (submodule: allow erroneous values for the fetchRecurseSubmodules option, 2015-08-17), we add submodule-config code that is later used to parse whether we are interested in updating submodules. We need the `die_on_error` parameter to be able to call this parsing function for the config file as well, which if incorrect lets Git die. As we're just touching the header file, also mark all functions extern. Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-14 22:46:32 +01:00
extern int parse_fetch_recurse_submodules_arg(const char *opt, const char *arg);
builtin/fetch: factor submodule recurse parsing out to submodule config Later we want to access this parsing in builtin/pull as well. Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-23 21:13:00 +02:00
struct option;
extern int option_fetch_parse_recurse_submodules(const struct option *opt,
const char *arg, int unset);
update submodules: add submodule config parsing Similar to b33a15b08 (push: add recurseSubmodules config option, 2015-11-17) and 027771fcb1 (submodule: allow erroneous values for the fetchRecurseSubmodules option, 2015-08-17), we add submodule-config code that is later used to parse whether we are interested in updating submodules. We need the `die_on_error` parameter to be able to call this parsing function for the config file as well, which if incorrect lets Git die. As we're just touching the header file, also mark all functions extern. Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-14 22:46:32 +01:00
extern int parse_update_recurse_submodules_arg(const char *opt, const char *arg);
extern int parse_push_recurse_submodules_arg(const char *opt, const char *arg);
submodule-config: move submodule-config functions to submodule-config.c Migrate the functions used to initialize the submodule-config to submodule-config.c so that the callback routine used in the initialization process can be static and prevent it from being used outside of initializing the submodule-config through the main API. Signed-off-by: Brandon Williams <bmwill@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-08-03 20:19:57 +02:00
extern void repo_read_gitmodules(struct repository *repo);
extern void gitmodules_config_oid(const struct object_id *commit_oid);
submodule-config: add repository argument to submodule_from_{name, path} This enables submodule_from_{name, path} to handle arbitrary repositories. All callers just pass in the_repository, a later patch will pass in other repos. While at it remove the extern key word from the declarations. Reviewed-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Stefan Beller <sbeller@google.com> Reviewed-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-03-29 00:35:29 +02:00
const struct submodule *submodule_from_name(struct repository *r,
const struct object_id *commit_or_tree,
const char *name);
const struct submodule *submodule_from_path(struct repository *r,
const struct object_id *commit_or_tree,
const char *path);
submodule-config: allow submodule_free to handle arbitrary repositories At some point we may want to rename the function so that it describes what it actually does as 'submodule_free' doesn't quite describe that this clears a repository's submodule cache. But that's beyond the scope of this series. While at it remove the extern key word from its declaration. Signed-off-by: Stefan Beller <sbeller@google.com> Reviewed-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-03-29 00:35:28 +02:00
void submodule_free(struct repository *r);
submodule: implement a config API for lookup of .gitmodules values In a superproject some commands need to interact with submodules. They need to query values from the .gitmodules file either from the worktree of from certain revisions. At the moment this is quite hard since a caller would need to read the .gitmodules file from the history and then parse the values. We want to provide an API for this so we have one place to get values from .gitmodules from any revision (including the worktree). The API is realized as a cache which allows us to lazily read .gitmodules configurations by commit into a runtime cache which can then be used to easily lookup values from it. Currently only the values for path or name are stored but it can be extended for any value needed. It is expected that .gitmodules files do not change often between commits. Thats why we lookup the .gitmodules sha1 from a commit and then either lookup an already parsed configuration or parse and cache an unknown one for each sha1. The cache is lazily build on demand for each requested commit. This cache can be used for all purposes which need knowledge about submodule configurations. Example use cases are: * Recursive submodule checkout needs to lookup a submodule name from its path when a submodule first appears. This needs be done before this configuration exists in the worktree. * The implementation of submodule support for 'git archive' needs to lookup the submodule name to generate the archive when given a revision that is not checked out. * 'git fetch' when given the --recurse-submodules=on-demand option (or configuration) needs to lookup submodule names by path from the database rather than reading from the worktree. For new submodule it needs to lookup the name from its path to allow cloning new submodules into the .git folder so they can be checked out without any network interaction when the user does a checkout of that revision. Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net> Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-08-18 02:21:57 +02:00
submodule-config: verify submodule names as paths Submodule "names" come from the untrusted .gitmodules file, but we blindly append them to $GIT_DIR/modules to create our on-disk repo paths. This means you can do bad things by putting "../" into the name (among other things). Let's sanity-check these names to avoid building a path that can be exploited. There are two main decisions: 1. What should the allowed syntax be? It's tempting to reuse verify_path(), since submodule names typically come from in-repo paths. But there are two reasons not to: a. It's technically more strict than what we need, as we really care only about breaking out of the $GIT_DIR/modules/ hierarchy. E.g., having a submodule named "foo/.git" isn't actually dangerous, and it's possible that somebody has manually given such a funny name. b. Since we'll eventually use this checking logic in fsck to prevent downstream repositories, it should be consistent across platforms. Because verify_path() relies on is_dir_sep(), it wouldn't block "foo\..\bar" on a non-Windows machine. 2. Where should we enforce it? These days most of the .gitmodules reads go through submodule-config.c, so I've put it there in the reading step. That should cover all of the C code. We also construct the name for "git submodule add" inside the git-submodule.sh script. This is probably not a big deal for security since the name is coming from the user anyway, but it would be polite to remind them if the name they pick is invalid (and we need to expose the name-checker to the shell anyway for our test scripts). This patch issues a warning when reading .gitmodules and just ignores the related config entry completely. This will generally end up producing a sensible error, as it works the same as a .gitmodules file which is missing a submodule entry (so "submodule update" will barf, but "git clone --recurse-submodules" will print an error but not abort the clone. There is one minor oddity, which is that we print the warning once per malformed config key (since that's how the config subsystem gives us the entries). So in the new test, for example, the user would see three warnings. That's OK, since the intent is that this case should never come up outside of malicious repositories (and then it might even benefit the user to see the message multiple times). Credit for finding this vulnerability and the proof of concept from which the test script was adapted goes to Etienne Stalmans. Signed-off-by: Jeff King <peff@peff.net>
2018-04-30 09:25:25 +02:00
/*
* Returns 0 if the name is syntactically acceptable as a submodule "name"
* (e.g., that may be found in the subsection of a .gitmodules file) and -1
* otherwise.
*/
int check_submodule_name(const char *name);
config: move config_from_gitmodules to submodule-config.c The .gitmodules file is not meant as a place to store arbitrary configuration to distribute with the repository. Move config_from_gitmodules() out of config.c and into submodule-config.c to make it even clearer that it is not a mechanism to retrieve arbitrary configuration from the .gitmodules file. Signed-off-by: Antonio Ospite <ao2@ao2.it> Acked-by: Brandon Williams <bmwill@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-26 12:47:05 +02:00
/*
submodule-config: make 'config_from_gitmodules' private Now that 'config_from_gitmodules' is not used in the open, it can be marked as private. Hopefully this will prevent its usage for retrieving arbitrary configuration form the '.gitmodules' file. Signed-off-by: Antonio Ospite <ao2@ao2.it> Acked-by: Brandon Williams <bmwill@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-26 12:47:08 +02:00
* Note: these helper functions exist solely to maintain backward
* compatibility with 'fetch' and 'update_clone' storing configuration in
* '.gitmodules'.
config: move config_from_gitmodules to submodule-config.c The .gitmodules file is not meant as a place to store arbitrary configuration to distribute with the repository. Move config_from_gitmodules() out of config.c and into submodule-config.c to make it even clearer that it is not a mechanism to retrieve arbitrary configuration from the .gitmodules file. Signed-off-by: Antonio Ospite <ao2@ao2.it> Acked-by: Brandon Williams <bmwill@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-26 12:47:05 +02:00
*
submodule-config: make 'config_from_gitmodules' private Now that 'config_from_gitmodules' is not used in the open, it can be marked as private. Hopefully this will prevent its usage for retrieving arbitrary configuration form the '.gitmodules' file. Signed-off-by: Antonio Ospite <ao2@ao2.it> Acked-by: Brandon Williams <bmwill@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-26 12:47:08 +02:00
* New helpers to retrieve arbitrary configuration from the '.gitmodules' file
* should NOT be added.
config: move config_from_gitmodules to submodule-config.c The .gitmodules file is not meant as a place to store arbitrary configuration to distribute with the repository. Move config_from_gitmodules() out of config.c and into submodule-config.c to make it even clearer that it is not a mechanism to retrieve arbitrary configuration from the .gitmodules file. Signed-off-by: Antonio Ospite <ao2@ao2.it> Acked-by: Brandon Williams <bmwill@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-26 12:47:05 +02:00
*/
submodule-config: add helper function to get 'fetch' config from .gitmodules Add a helper function to make it clearer that retrieving 'fetch' configuration from the .gitmodules file is a special case supported solely for backward compatibility purposes. This change removes one direct use of 'config_from_gitmodules' in code not strictly related to submodules, in the effort to communicate better that .gitmodules is not to be used as a mechanism to store arbitrary configuration in the repository that any command can retrieve. Signed-off-by: Antonio Ospite <ao2@ao2.it> Acked-by: Brandon Williams <bmwill@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-26 12:47:06 +02:00
extern void fetch_config_from_gitmodules(int *max_children, int *recurse_submodules);
submodule-config: add helper to get 'update-clone' config from .gitmodules Add a helper function to make it clearer that retrieving 'update-clone' configuration from the .gitmodules file is a special case supported solely for backward compatibility purposes. This change removes one direct use of 'config_from_gitmodules' for options not strictly related to submodules: "submodule.fetchjobs" does not describe a property of a submodule, but a behavior of other commands when dealing with submodules, so it does not really belong to the .gitmodules file. This is in the effort to communicate better that .gitmodules is not to be used as a mechanism to store arbitrary configuration in the repository that any command can retrieve. Signed-off-by: Antonio Ospite <ao2@ao2.it> Acked-by: Brandon Williams <bmwill@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-26 12:47:07 +02:00
extern void update_clone_config_from_gitmodules(int *max_jobs);
submodule-config: add helper function to get 'fetch' config from .gitmodules Add a helper function to make it clearer that retrieving 'fetch' configuration from the .gitmodules file is a special case supported solely for backward compatibility purposes. This change removes one direct use of 'config_from_gitmodules' in code not strictly related to submodules, in the effort to communicate better that .gitmodules is not to be used as a mechanism to store arbitrary configuration in the repository that any command can retrieve. Signed-off-by: Antonio Ospite <ao2@ao2.it> Acked-by: Brandon Williams <bmwill@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-26 12:47:06 +02:00
submodule: implement a config API for lookup of .gitmodules values In a superproject some commands need to interact with submodules. They need to query values from the .gitmodules file either from the worktree of from certain revisions. At the moment this is quite hard since a caller would need to read the .gitmodules file from the history and then parse the values. We want to provide an API for this so we have one place to get values from .gitmodules from any revision (including the worktree). The API is realized as a cache which allows us to lazily read .gitmodules configurations by commit into a runtime cache which can then be used to easily lookup values from it. Currently only the values for path or name are stored but it can be extended for any value needed. It is expected that .gitmodules files do not change often between commits. Thats why we lookup the .gitmodules sha1 from a commit and then either lookup an already parsed configuration or parse and cache an unknown one for each sha1. The cache is lazily build on demand for each requested commit. This cache can be used for all purposes which need knowledge about submodule configurations. Example use cases are: * Recursive submodule checkout needs to lookup a submodule name from its path when a submodule first appears. This needs be done before this configuration exists in the worktree. * The implementation of submodule support for 'git archive' needs to lookup the submodule name to generate the archive when given a revision that is not checked out. * 'git fetch' when given the --recurse-submodules=on-demand option (or configuration) needs to lookup submodule names by path from the database rather than reading from the worktree. For new submodule it needs to lookup the name from its path to allow cloning new submodules into the .git folder so they can be checked out without any network interaction when the user does a checkout of that revision. Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net> Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-08-18 02:21:57 +02:00
#endif /* SUBMODULE_CONFIG_H */
Copy permalink