"W. Trevor King" <[email protected]> writes:
> From: "W. Trevor King" <[email protected]>
>
> Several submodule configuration variables
> (e.g. fetchRecurseSubmodules) are read from .gitmodules with local
> overrides from the usual git config files. This shell function mimics
> that logic to help initialize configuration variables in
> git-submodule.sh.
>
> Signed-off-by: W. Trevor King <[email protected]>
> ---
> git-submodule.sh | 27 +++++++++++++++++++++++++++
> 1 file changed, 27 insertions(+)
>
> diff --git a/git-submodule.sh b/git-submodule.sh
> index ab6b110..97ce5e4 100755
> --- a/git-submodule.sh
> +++ b/git-submodule.sh
> @@ -152,6 +152,33 @@ die_if_unmatched ()
> }
>
> #
> +# Print a submodule configuration setting
> +#
> +# $1 = submodule name
> +# $2 = option name
> +# $3 = default value
> +#
> +# Checks in the usual git-config places first (for overrides),
> +# otherwise it falls back on .gitmodules. This allows you to
> +# distribute project-wide defaults in .gitmodules, while still
> +# customizing individual repositories if necessary. If the option is
> +# not in .gitmodules either, print a default value.
> +#
> +get_submodule_config()
> +{
style (see CodingGuidelines):
get_submodule_config () {
> + name="$1"
> + option="$2"
> + default="$3"
> + value=$(git config submodule."$name"."$option")
This will get unwieldy quickly once we have submodule.$name.$var
that takes a boolean option, as there are different ways to spell
boolean and "git config --bool" is the way to ask for canonicalized
"true" or "false".
If we never query any boolean via this helper function, it is
obviously not an issue, though.
> + if test -z "$value"
> + then
> + value=$(git config -f .gitmodules submodule."$name"."$option")
> + fi
> + printf '%s' "${value:-$default}"
> +}
> +
> +
> +#
> # Map submodule path to submodule name
> #
> # $1 = path
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
