Re: [PATCH v4 1/4] implement submodule config cache for lookup of submodule names

> This submodule configuration cache 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 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.

> diff --git a/Documentation/technical/api-submodule-config.txt b/Documentation/technical/api-submodule-config.txt
> new file mode 100644
> index 0000000..2ff4907
> --- /dev/null
> +++ b/Documentation/technical/api-submodule-config.txt
> @@ -0,0 +1,46 @@
> +submodule config cache API
> +==========================
> +
> +The submodule config cache API allows to read submodule
> +configurations/information from specified revisions. Internally
> +information is lazily read into a cache that is used to avoid
> +unnecessary parsing of the same .gitmodule files. Lookups can be done by
> +submodule path or name.
> +
> +Usage
> +-----
> +
> +The caller can look up information about submodules by using the
> +`submodule_from_path()` or `submodule_from_name()` functions. They return
> +a `struct submodule` which contains the values. The API automatically
> +initializes and allocates the needed infrastructure on-demand.
> +
> +If the internal cache might grow too big or when the caller is done with
> +the API, all internally cached values can be freed with submodule_free().
> +
> +Data Structures
> +---------------
> +
> +`struct submodule`::
> +
> +	This structure is used to return the information about one
> +	submodule for a certain revision. It is returned by the lookup
> +	functions.

> +Functions
> +---------
> +
> +`void submodule_free()`::
> +
> +	Use these to free the internally cached values.

> diff --git a/submodule-config.c b/submodule-config.c
> new file mode 100644
> index 0000000..97f4a04
> --- /dev/null
> +++ b/submodule-config.c
> @@ -0,0 +1,445 @@
> +#include "cache.h"
> +#include "submodule-config.h"
> +#include "submodule.h"
> +#include "strbuf.h"
> +
> +/*
> + * submodule cache lookup structure
> + * There is one shared set of 'struct submodule' entries which can be
> + * looked up by their sha1 blob id of the .gitmodule file and either
> + * using path or name as key.
> + * for_path stores submodule entries with path as key
> + * for_name stores submodule entries with name as key
> + */
> +struct submodule_cache {
> +	struct hashmap for_path;
> +	struct hashmap for_name;
> +};
> +
> +/*
> + * thin wrapper struct needed to insert 'struct submodule' entries to
> + * the hashmap
> + */
> +struct submodule_entry {
> +	struct hashmap_entry ent;
> +	struct submodule *config;
> +};