config: add include directive
It can be useful to split your ~/.gitconfig across multiple
files. For example, you might have a "main" file which is
used on many machines, but a small set of per-machine
tweaks. Or you may want to make some of your config public
(e.g., clever aliases) while keeping other data back (e.g.,
your name or other identifying information). Or you may want
to include a number of config options in some subset of your
repos without copying and pasting (e.g., you want to
reference them from the .git/config of participating repos).
This patch introduces an include directive for config files.
It looks like:
[include]
path = /path/to/file
This is syntactically backwards-compatible with existing git
config parsers (i.e., they will see it as another config
entry and ignore it unless you are looking up include.path).
The implementation provides a "git_config_include" callback
which wraps regular config callbacks. Callers can pass it to
git_config_from_file, and it will transparently follow any
include directives, passing all of the discovered options to
the real callback.
Include directives are turned on automatically for "regular"
git config parsing. This includes calls to git_config, as
well as calls to the "git config" program that do not
specify a single file (e.g., using "-f", "--global", etc).
They are not turned on in other cases, including:
1. Parsing of other config-like files, like .gitmodules.
There isn't a real need, and I'd rather be conservative
and avoid unnecessary incompatibility or confusion.
2. Reading single files via "git config". This is for two
reasons:
a. backwards compatibility with scripts looking at
config-like files.
b. inspection of a specific file probably means you
care about just what's in that file, not a general
lookup for "do we have this value anywhere at
all". If that is not the case, the caller can
always specify "--includes".
3. Writing files via "git config"; we want to treat
include.* variables as literal items to be copied (or
modified), and not expand them. So "git config
--unset-all foo.bar" would operate _only_ on
.git/config, not any of its included files (just as it
also does not operate on ~/.gitconfig).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
13 years ago
|
|
|
#!/bin/sh
|
|
|
|
|
|
|
|
|
|
test_description='test config file include directives'
|
|
|
|
|
. ./test-lib.sh
|
|
|
|
|
|
|
|
|
|
# Force setup_explicit_git_dir() to run until the end. This is needed
|
|
|
|
|
# by some tests to make sure real_path() is called on $GIT_DIR. The
|
|
|
|
|
# caller needs to make sure git commands are run from a subdirectory
|
|
|
|
|
# though or real_path() will not be called.
|
|
|
|
|
force_setup_explicit_git_dir() {
|
|
|
|
|
GIT_DIR="$(pwd)/.git"
|
|
|
|
|
GIT_WORK_TREE="$(pwd)"
|
|
|
|
|
export GIT_DIR GIT_WORK_TREE
|
|
|
|
|
}
|
|
|
|
|
|
config: add include directive
It can be useful to split your ~/.gitconfig across multiple
files. For example, you might have a "main" file which is
used on many machines, but a small set of per-machine
tweaks. Or you may want to make some of your config public
(e.g., clever aliases) while keeping other data back (e.g.,
your name or other identifying information). Or you may want
to include a number of config options in some subset of your
repos without copying and pasting (e.g., you want to
reference them from the .git/config of participating repos).
This patch introduces an include directive for config files.
It looks like:
[include]
path = /path/to/file
This is syntactically backwards-compatible with existing git
config parsers (i.e., they will see it as another config
entry and ignore it unless you are looking up include.path).
The implementation provides a "git_config_include" callback
which wraps regular config callbacks. Callers can pass it to
git_config_from_file, and it will transparently follow any
include directives, passing all of the discovered options to
the real callback.
Include directives are turned on automatically for "regular"
git config parsing. This includes calls to git_config, as
well as calls to the "git config" program that do not
specify a single file (e.g., using "-f", "--global", etc).
They are not turned on in other cases, including:
1. Parsing of other config-like files, like .gitmodules.
There isn't a real need, and I'd rather be conservative
and avoid unnecessary incompatibility or confusion.
2. Reading single files via "git config". This is for two
reasons:
a. backwards compatibility with scripts looking at
config-like files.
b. inspection of a specific file probably means you
care about just what's in that file, not a general
lookup for "do we have this value anywhere at
all". If that is not the case, the caller can
always specify "--includes".
3. Writing files via "git config"; we want to treat
include.* variables as literal items to be copied (or
modified), and not expand them. So "git config
--unset-all foo.bar" would operate _only_ on
.git/config, not any of its included files (just as it
also does not operate on ~/.gitconfig).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
13 years ago
|
|
|
test_expect_success 'include file by absolute path' '
|
|
|
|
|
echo "[test]one = 1" >one &&
|
|
|
|
|
echo "[include]path = \"$(pwd)/one\"" >.gitconfig &&
|
|
|
|
|
echo 1 >expect &&
|
|
|
|
|
git config test.one >actual &&
|
|
|
|
|
test_cmp expect actual
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'include file by relative path' '
|
|
|
|
|
echo "[test]one = 1" >one &&
|
|
|
|
|
echo "[include]path = one" >.gitconfig &&
|
|
|
|
|
echo 1 >expect &&
|
|
|
|
|
git config test.one >actual &&
|
|
|
|
|
test_cmp expect actual
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'chained relative paths' '
|
|
|
|
|
mkdir subdir &&
|
|
|
|
|
echo "[test]three = 3" >subdir/three &&
|
|
|
|
|
echo "[include]path = three" >subdir/two &&
|
|
|
|
|
echo "[include]path = subdir/two" >.gitconfig &&
|
|
|
|
|
echo 3 >expect &&
|
|
|
|
|
git config test.three >actual &&
|
|
|
|
|
test_cmp expect actual
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'include paths get tilde-expansion' '
|
|
|
|
|
echo "[test]one = 1" >one &&
|
|
|
|
|
echo "[include]path = ~/one" >.gitconfig &&
|
|
|
|
|
echo 1 >expect &&
|
|
|
|
|
git config test.one >actual &&
|
|
|
|
|
test_cmp expect actual
|
|
|
|
|
'
|
|
|
|
|
|
config: add include directive
It can be useful to split your ~/.gitconfig across multiple
files. For example, you might have a "main" file which is
used on many machines, but a small set of per-machine
tweaks. Or you may want to make some of your config public
(e.g., clever aliases) while keeping other data back (e.g.,
your name or other identifying information). Or you may want
to include a number of config options in some subset of your
repos without copying and pasting (e.g., you want to
reference them from the .git/config of participating repos).
This patch introduces an include directive for config files.
It looks like:
[include]
path = /path/to/file
This is syntactically backwards-compatible with existing git
config parsers (i.e., they will see it as another config
entry and ignore it unless you are looking up include.path).
The implementation provides a "git_config_include" callback
which wraps regular config callbacks. Callers can pass it to
git_config_from_file, and it will transparently follow any
include directives, passing all of the discovered options to
the real callback.
Include directives are turned on automatically for "regular"
git config parsing. This includes calls to git_config, as
well as calls to the "git config" program that do not
specify a single file (e.g., using "-f", "--global", etc).
They are not turned on in other cases, including:
1. Parsing of other config-like files, like .gitmodules.
There isn't a real need, and I'd rather be conservative
and avoid unnecessary incompatibility or confusion.
2. Reading single files via "git config". This is for two
reasons:
a. backwards compatibility with scripts looking at
config-like files.
b. inspection of a specific file probably means you
care about just what's in that file, not a general
lookup for "do we have this value anywhere at
all". If that is not the case, the caller can
always specify "--includes".
3. Writing files via "git config"; we want to treat
include.* variables as literal items to be copied (or
modified), and not expand them. So "git config
--unset-all foo.bar" would operate _only_ on
.git/config, not any of its included files (just as it
also does not operate on ~/.gitconfig).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
13 years ago
|
|
|
test_expect_success 'include options can still be examined' '
|
|
|
|
|
echo "[test]one = 1" >one &&
|
|
|
|
|
echo "[include]path = one" >.gitconfig &&
|
|
|
|
|
echo one >expect &&
|
|
|
|
|
git config include.path >actual &&
|
|
|
|
|
test_cmp expect actual
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'listing includes option and expansion' '
|
|
|
|
|
echo "[test]one = 1" >one &&
|
|
|
|
|
echo "[include]path = one" >.gitconfig &&
|
|
|
|
|
cat >expect <<-\EOF &&
|
|
|
|
|
include.path=one
|
|
|
|
|
test.one=1
|
|
|
|
|
EOF
|
|
|
|
|
git config --list >actual.full &&
|
|
|
|
|
grep -v -e ^core -e ^extensions actual.full >actual &&
|
config: add include directive
It can be useful to split your ~/.gitconfig across multiple
files. For example, you might have a "main" file which is
used on many machines, but a small set of per-machine
tweaks. Or you may want to make some of your config public
(e.g., clever aliases) while keeping other data back (e.g.,
your name or other identifying information). Or you may want
to include a number of config options in some subset of your
repos without copying and pasting (e.g., you want to
reference them from the .git/config of participating repos).
This patch introduces an include directive for config files.
It looks like:
[include]
path = /path/to/file
This is syntactically backwards-compatible with existing git
config parsers (i.e., they will see it as another config
entry and ignore it unless you are looking up include.path).
The implementation provides a "git_config_include" callback
which wraps regular config callbacks. Callers can pass it to
git_config_from_file, and it will transparently follow any
include directives, passing all of the discovered options to
the real callback.
Include directives are turned on automatically for "regular"
git config parsing. This includes calls to git_config, as
well as calls to the "git config" program that do not
specify a single file (e.g., using "-f", "--global", etc).
They are not turned on in other cases, including:
1. Parsing of other config-like files, like .gitmodules.
There isn't a real need, and I'd rather be conservative
and avoid unnecessary incompatibility or confusion.
2. Reading single files via "git config". This is for two
reasons:
a. backwards compatibility with scripts looking at
config-like files.
b. inspection of a specific file probably means you
care about just what's in that file, not a general
lookup for "do we have this value anywhere at
all". If that is not the case, the caller can
always specify "--includes".
3. Writing files via "git config"; we want to treat
include.* variables as literal items to be copied (or
modified), and not expand them. So "git config
--unset-all foo.bar" would operate _only_ on
.git/config, not any of its included files (just as it
also does not operate on ~/.gitconfig).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
13 years ago
|
|
|
test_cmp expect actual
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'single file lookup does not expand includes by default' '
|
|
|
|
|
echo "[test]one = 1" >one &&
|
|
|
|
|
echo "[include]path = one" >.gitconfig &&
|
|
|
|
|
test_must_fail git config -f .gitconfig test.one &&
|
|
|
|
|
test_must_fail git config --global test.one &&
|
|
|
|
|
echo 1 >expect &&
|
|
|
|
|
git config --includes -f .gitconfig test.one >actual &&
|
|
|
|
|
test_cmp expect actual
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'single file list does not expand includes by default' '
|
|
|
|
|
echo "[test]one = 1" >one &&
|
|
|
|
|
echo "[include]path = one" >.gitconfig &&
|
|
|
|
|
echo "include.path=one" >expect &&
|
|
|
|
|
git config -f .gitconfig --list >actual &&
|
|
|
|
|
test_cmp expect actual
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'writing config file does not expand includes' '
|
|
|
|
|
echo "[test]one = 1" >one &&
|
|
|
|
|
echo "[include]path = one" >.gitconfig &&
|
|
|
|
|
git config test.two 2 &&
|
|
|
|
|
echo 2 >expect &&
|
|
|
|
|
git config --no-includes test.two >actual &&
|
|
|
|
|
test_cmp expect actual &&
|
|
|
|
|
test_must_fail git config --no-includes test.one
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'config modification does not affect includes' '
|
|
|
|
|
echo "[test]one = 1" >one &&
|
|
|
|
|
echo "[include]path = one" >.gitconfig &&
|
|
|
|
|
git config test.one 2 &&
|
|
|
|
|
echo 1 >expect &&
|
|
|
|
|
git config -f one test.one >actual &&
|
|
|
|
|
test_cmp expect actual &&
|
|
|
|
|
cat >expect <<-\EOF &&
|
|
|
|
|
1
|
|
|
|
|
2
|
|
|
|
|
EOF
|
|
|
|
|
git config --get-all test.one >actual &&
|
|
|
|
|
test_cmp expect actual
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'missing include files are ignored' '
|
|
|
|
|
cat >.gitconfig <<-\EOF &&
|
config: add conditional include
Sometimes a set of repositories want to share configuration settings
among themselves that are distinct from other such sets of repositories.
A user may work on two projects, each of which have multiple
repositories, and use one user.email for one project while using another
for the other.
Setting $GIT_DIR/.config works, but if the penalty of forgetting to
update $GIT_DIR/.config is high (especially when you end up cloning
often), it may not be the best way to go. Having the settings in
~/.gitconfig, which would work for just one set of repositories, would
not well in such a situation. Having separate ${HOME}s may add more
problems than it solves.
Extend the include.path mechanism that lets a config file include
another config file, so that the inclusion can be done only when some
conditions hold. Then ~/.gitconfig can say "include config-project-A
only when working on project-A" for each project A the user works on.
In this patch, the only supported grouping is based on $GIT_DIR (in
absolute path), so you would need to group repositories by directory, or
something like that to take advantage of it.
We already have include.path for unconditional includes. This patch goes
with includeIf.<condition>.path to make it clearer that a condition is
required. The new config has the same backward compatibility approach as
include.path: older git versions that don't understand includeIf will
simply ignore them.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
8 years ago
|
|
|
[include]path = non-existent
|
config: add include directive
It can be useful to split your ~/.gitconfig across multiple
files. For example, you might have a "main" file which is
used on many machines, but a small set of per-machine
tweaks. Or you may want to make some of your config public
(e.g., clever aliases) while keeping other data back (e.g.,
your name or other identifying information). Or you may want
to include a number of config options in some subset of your
repos without copying and pasting (e.g., you want to
reference them from the .git/config of participating repos).
This patch introduces an include directive for config files.
It looks like:
[include]
path = /path/to/file
This is syntactically backwards-compatible with existing git
config parsers (i.e., they will see it as another config
entry and ignore it unless you are looking up include.path).
The implementation provides a "git_config_include" callback
which wraps regular config callbacks. Callers can pass it to
git_config_from_file, and it will transparently follow any
include directives, passing all of the discovered options to
the real callback.
Include directives are turned on automatically for "regular"
git config parsing. This includes calls to git_config, as
well as calls to the "git config" program that do not
specify a single file (e.g., using "-f", "--global", etc).
They are not turned on in other cases, including:
1. Parsing of other config-like files, like .gitmodules.
There isn't a real need, and I'd rather be conservative
and avoid unnecessary incompatibility or confusion.
2. Reading single files via "git config". This is for two
reasons:
a. backwards compatibility with scripts looking at
config-like files.
b. inspection of a specific file probably means you
care about just what's in that file, not a general
lookup for "do we have this value anywhere at
all". If that is not the case, the caller can
always specify "--includes".
3. Writing files via "git config"; we want to treat
include.* variables as literal items to be copied (or
modified), and not expand them. So "git config
--unset-all foo.bar" would operate _only_ on
.git/config, not any of its included files (just as it
also does not operate on ~/.gitconfig).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
13 years ago
|
|
|
[test]value = yes
|
|
|
|
|
EOF
|
|
|
|
|
echo yes >expect &&
|
|
|
|
|
git config test.value >actual &&
|
|
|
|
|
test_cmp expect actual
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'absolute includes from command line work' '
|
|
|
|
|
echo "[test]one = 1" >one &&
|
|
|
|
|
echo 1 >expect &&
|
|
|
|
|
git -c include.path="$(pwd)/one" config test.one >actual &&
|
config: add include directive
It can be useful to split your ~/.gitconfig across multiple
files. For example, you might have a "main" file which is
used on many machines, but a small set of per-machine
tweaks. Or you may want to make some of your config public
(e.g., clever aliases) while keeping other data back (e.g.,
your name or other identifying information). Or you may want
to include a number of config options in some subset of your
repos without copying and pasting (e.g., you want to
reference them from the .git/config of participating repos).
This patch introduces an include directive for config files.
It looks like:
[include]
path = /path/to/file
This is syntactically backwards-compatible with existing git
config parsers (i.e., they will see it as another config
entry and ignore it unless you are looking up include.path).
The implementation provides a "git_config_include" callback
which wraps regular config callbacks. Callers can pass it to
git_config_from_file, and it will transparently follow any
include directives, passing all of the discovered options to
the real callback.
Include directives are turned on automatically for "regular"
git config parsing. This includes calls to git_config, as
well as calls to the "git config" program that do not
specify a single file (e.g., using "-f", "--global", etc).
They are not turned on in other cases, including:
1. Parsing of other config-like files, like .gitmodules.
There isn't a real need, and I'd rather be conservative
and avoid unnecessary incompatibility or confusion.
2. Reading single files via "git config". This is for two
reasons:
a. backwards compatibility with scripts looking at
config-like files.
b. inspection of a specific file probably means you
care about just what's in that file, not a general
lookup for "do we have this value anywhere at
all". If that is not the case, the caller can
always specify "--includes".
3. Writing files via "git config"; we want to treat
include.* variables as literal items to be copied (or
modified), and not expand them. So "git config
--unset-all foo.bar" would operate _only_ on
.git/config, not any of its included files (just as it
also does not operate on ~/.gitconfig).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
13 years ago
|
|
|
test_cmp expect actual
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'relative includes from command line fail' '
|
|
|
|
|
echo "[test]one = 1" >one &&
|
|
|
|
|
test_must_fail git -c include.path=one config test.one
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'absolute includes from blobs work' '
|
|
|
|
|
echo "[test]one = 1" >one &&
|
|
|
|
|
echo "[include]path=$(pwd)/one" >blob &&
|
|
|
|
|
blob=$(git hash-object -w blob) &&
|
|
|
|
|
echo 1 >expect &&
|
|
|
|
|
git config --blob=$blob test.one >actual &&
|
|
|
|
|
test_cmp expect actual
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'relative includes from blobs fail' '
|
|
|
|
|
echo "[test]one = 1" >one &&
|
|
|
|
|
echo "[include]path=one" >blob &&
|
|
|
|
|
blob=$(git hash-object -w blob) &&
|
|
|
|
|
test_must_fail git config --blob=$blob test.one
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'absolute includes from stdin work' '
|
|
|
|
|
echo "[test]one = 1" >one &&
|
|
|
|
|
echo 1 >expect &&
|
|
|
|
|
echo "[include]path=\"$(pwd)/one\"" |
|
|
|
|
|
git config --file - test.one >actual &&
|
|
|
|
|
test_cmp expect actual
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'relative includes from stdin line fail' '
|
|
|
|
|
echo "[test]one = 1" >one &&
|
|
|
|
|
echo "[include]path=one" |
|
|
|
|
|
test_must_fail git config --file - test.one
|
|
|
|
|
'
|
|
|
|
|
|
config: add conditional include
Sometimes a set of repositories want to share configuration settings
among themselves that are distinct from other such sets of repositories.
A user may work on two projects, each of which have multiple
repositories, and use one user.email for one project while using another
for the other.
Setting $GIT_DIR/.config works, but if the penalty of forgetting to
update $GIT_DIR/.config is high (especially when you end up cloning
often), it may not be the best way to go. Having the settings in
~/.gitconfig, which would work for just one set of repositories, would
not well in such a situation. Having separate ${HOME}s may add more
problems than it solves.
Extend the include.path mechanism that lets a config file include
another config file, so that the inclusion can be done only when some
conditions hold. Then ~/.gitconfig can say "include config-project-A
only when working on project-A" for each project A the user works on.
In this patch, the only supported grouping is based on $GIT_DIR (in
absolute path), so you would need to group repositories by directory, or
something like that to take advantage of it.
We already have include.path for unconditional includes. This patch goes
with includeIf.<condition>.path to make it clearer that a condition is
required. The new config has the same backward compatibility approach as
include.path: older git versions that don't understand includeIf will
simply ignore them.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
8 years ago
|
|
|
test_expect_success 'conditional include, both unanchored' '
|
|
|
|
|
git init foo &&
|
|
|
|
|
(
|
|
|
|
|
cd foo &&
|
|
|
|
|
echo "[includeIf \"gitdir:foo/\"]path=bar" >>.git/config &&
|
|
|
|
|
echo "[test]one=1" >.git/bar &&
|
|
|
|
|
echo 1 >expect &&
|
|
|
|
|
git config test.one >actual &&
|
|
|
|
|
test_cmp expect actual
|
|
|
|
|
)
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'conditional include, $HOME expansion' '
|
|
|
|
|
(
|
|
|
|
|
cd foo &&
|
|
|
|
|
echo "[includeIf \"gitdir:~/foo/\"]path=bar2" >>.git/config &&
|
|
|
|
|
echo "[test]two=2" >.git/bar2 &&
|
|
|
|
|
echo 2 >expect &&
|
|
|
|
|
git config test.two >actual &&
|
|
|
|
|
test_cmp expect actual
|
|
|
|
|
)
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'conditional include, full pattern' '
|
|
|
|
|
(
|
|
|
|
|
cd foo &&
|
|
|
|
|
echo "[includeIf \"gitdir:**/foo/**\"]path=bar3" >>.git/config &&
|
|
|
|
|
echo "[test]three=3" >.git/bar3 &&
|
|
|
|
|
echo 3 >expect &&
|
|
|
|
|
git config test.three >actual &&
|
|
|
|
|
test_cmp expect actual
|
|
|
|
|
)
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'conditional include, relative path' '
|
|
|
|
|
echo "[includeIf \"gitdir:./foo/.git\"]path=bar4" >>.gitconfig &&
|
|
|
|
|
echo "[test]four=4" >bar4 &&
|
|
|
|
|
(
|
|
|
|
|
cd foo &&
|
|
|
|
|
echo 4 >expect &&
|
|
|
|
|
git config test.four >actual &&
|
|
|
|
|
test_cmp expect actual
|
|
|
|
|
)
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'conditional include, both unanchored, icase' '
|
|
|
|
|
(
|
|
|
|
|
cd foo &&
|
|
|
|
|
echo "[includeIf \"gitdir/i:FOO/\"]path=bar5" >>.git/config &&
|
|
|
|
|
echo "[test]five=5" >.git/bar5 &&
|
|
|
|
|
echo 5 >expect &&
|
|
|
|
|
git config test.five >actual &&
|
|
|
|
|
test_cmp expect actual
|
|
|
|
|
)
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'conditional include, early config reading' '
|
|
|
|
|
(
|
|
|
|
|
cd foo &&
|
|
|
|
|
echo "[includeIf \"gitdir:foo/\"]path=bar6" >>.git/config &&
|
|
|
|
|
echo "[test]six=6" >.git/bar6 &&
|
|
|
|
|
echo 6 >expect &&
|
|
|
|
|
test-tool config read_early_config test.six >actual &&
|
|
|
|
|
test_cmp expect actual
|
|
|
|
|
)
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'conditional include with /**/' '
|
|
|
|
|
REPO=foo/bar/repo &&
|
|
|
|
|
git init $REPO &&
|
|
|
|
|
cat >>$REPO/.git/config <<-\EOF &&
|
|
|
|
|
[includeIf "gitdir:**/foo/**/bar/**"]
|
|
|
|
|
path=bar7
|
|
|
|
|
EOF
|
|
|
|
|
echo "[test]seven=7" >$REPO/.git/bar7 &&
|
|
|
|
|
echo 7 >expect &&
|
|
|
|
|
git -C $REPO config test.seven >actual &&
|
|
|
|
|
test_cmp expect actual
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success SYMLINKS 'conditional include, set up symlinked $HOME' '
|
|
|
|
|
mkdir real-home &&
|
|
|
|
|
ln -s real-home home &&
|
|
|
|
|
(
|
|
|
|
|
HOME="$TRASH_DIRECTORY/home" &&
|
|
|
|
|
export HOME &&
|
|
|
|
|
cd "$HOME" &&
|
|
|
|
|
|
|
|
|
|
git init foo &&
|
|
|
|
|
cd foo &&
|
|
|
|
|
mkdir sub
|
|
|
|
|
)
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success SYMLINKS 'conditional include, $HOME expansion with symlinks' '
|
|
|
|
|
(
|
|
|
|
|
HOME="$TRASH_DIRECTORY/home" &&
|
|
|
|
|
export HOME &&
|
|
|
|
|
cd "$HOME"/foo &&
|
|
|
|
|
|
|
|
|
|
echo "[includeIf \"gitdir:~/foo/\"]path=bar2" >>.git/config &&
|
|
|
|
|
echo "[test]two=2" >.git/bar2 &&
|
|
|
|
|
echo 2 >expect &&
|
|
|
|
|
force_setup_explicit_git_dir &&
|
|
|
|
|
git -C sub config test.two >actual &&
|
|
|
|
|
test_cmp expect actual
|
|
|
|
|
)
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success SYMLINKS 'conditional include, relative path with symlinks' '
|
|
|
|
|
echo "[includeIf \"gitdir:./foo/.git\"]path=bar4" >home/.gitconfig &&
|
|
|
|
|
echo "[test]four=4" >home/bar4 &&
|
|
|
|
|
(
|
|
|
|
|
HOME="$TRASH_DIRECTORY/home" &&
|
|
|
|
|
export HOME &&
|
|
|
|
|
cd "$HOME"/foo &&
|
|
|
|
|
|
|
|
|
|
echo 4 >expect &&
|
|
|
|
|
force_setup_explicit_git_dir &&
|
|
|
|
|
git -C sub config test.four >actual &&
|
|
|
|
|
test_cmp expect actual
|
|
|
|
|
)
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success SYMLINKS 'conditional include, gitdir matching symlink' '
|
|
|
|
|
ln -s foo bar &&
|
|
|
|
|
(
|
|
|
|
|
cd bar &&
|
|
|
|
|
echo "[includeIf \"gitdir:bar/\"]path=bar7" >>.git/config &&
|
|
|
|
|
echo "[test]seven=7" >.git/bar7 &&
|
|
|
|
|
echo 7 >expect &&
|
|
|
|
|
git config test.seven >actual &&
|
|
|
|
|
test_cmp expect actual
|
|
|
|
|
)
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success SYMLINKS 'conditional include, gitdir matching symlink, icase' '
|
|
|
|
|
(
|
|
|
|
|
cd bar &&
|
|
|
|
|
echo "[includeIf \"gitdir/i:BAR/\"]path=bar8" >>.git/config &&
|
|
|
|
|
echo "[test]eight=8" >.git/bar8 &&
|
|
|
|
|
echo 8 >expect &&
|
|
|
|
|
git config test.eight >actual &&
|
|
|
|
|
test_cmp expect actual
|
|
|
|
|
)
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'conditional include, onbranch' '
|
|
|
|
|
echo "[includeIf \"onbranch:foo-branch\"]path=bar9" >>.git/config &&
|
|
|
|
|
echo "[test]nine=9" >.git/bar9 &&
|
|
|
|
|
git checkout -b master &&
|
|
|
|
|
test_must_fail git config test.nine &&
|
|
|
|
|
git checkout -b foo-branch &&
|
|
|
|
|
echo 9 >expect &&
|
|
|
|
|
git config test.nine >actual &&
|
|
|
|
|
test_cmp expect actual
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'conditional include, onbranch, wildcard' '
|
|
|
|
|
echo "[includeIf \"onbranch:?oo-*/**\"]path=bar10" >>.git/config &&
|
|
|
|
|
echo "[test]ten=10" >.git/bar10 &&
|
|
|
|
|
git checkout -b not-foo-branch/a &&
|
|
|
|
|
test_must_fail git config test.ten &&
|
|
|
|
|
|
|
|
|
|
echo 10 >expect &&
|
|
|
|
|
git checkout -b foo-branch/a/b/c &&
|
|
|
|
|
git config test.ten >actual &&
|
|
|
|
|
test_cmp expect actual &&
|
|
|
|
|
|
|
|
|
|
git checkout -b moo-bar/a &&
|
|
|
|
|
git config test.ten >actual &&
|
|
|
|
|
test_cmp expect actual
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'conditional include, onbranch, implicit /** for /' '
|
|
|
|
|
echo "[includeIf \"onbranch:foo-dir/\"]path=bar11" >>.git/config &&
|
|
|
|
|
echo "[test]eleven=11" >.git/bar11 &&
|
|
|
|
|
git checkout -b not-foo-dir/a &&
|
|
|
|
|
test_must_fail git config test.eleven &&
|
|
|
|
|
|
|
|
|
|
echo 11 >expect &&
|
|
|
|
|
git checkout -b foo-dir/a/b/c &&
|
|
|
|
|
git config test.eleven >actual &&
|
|
|
|
|
test_cmp expect actual
|
|
|
|
|
'
|
|
|
|
|
|
config: add include directive
It can be useful to split your ~/.gitconfig across multiple
files. For example, you might have a "main" file which is
used on many machines, but a small set of per-machine
tweaks. Or you may want to make some of your config public
(e.g., clever aliases) while keeping other data back (e.g.,
your name or other identifying information). Or you may want
to include a number of config options in some subset of your
repos without copying and pasting (e.g., you want to
reference them from the .git/config of participating repos).
This patch introduces an include directive for config files.
It looks like:
[include]
path = /path/to/file
This is syntactically backwards-compatible with existing git
config parsers (i.e., they will see it as another config
entry and ignore it unless you are looking up include.path).
The implementation provides a "git_config_include" callback
which wraps regular config callbacks. Callers can pass it to
git_config_from_file, and it will transparently follow any
include directives, passing all of the discovered options to
the real callback.
Include directives are turned on automatically for "regular"
git config parsing. This includes calls to git_config, as
well as calls to the "git config" program that do not
specify a single file (e.g., using "-f", "--global", etc).
They are not turned on in other cases, including:
1. Parsing of other config-like files, like .gitmodules.
There isn't a real need, and I'd rather be conservative
and avoid unnecessary incompatibility or confusion.
2. Reading single files via "git config". This is for two
reasons:
a. backwards compatibility with scripts looking at
config-like files.
b. inspection of a specific file probably means you
care about just what's in that file, not a general
lookup for "do we have this value anywhere at
all". If that is not the case, the caller can
always specify "--includes".
3. Writing files via "git config"; we want to treat
include.* variables as literal items to be copied (or
modified), and not expand them. So "git config
--unset-all foo.bar" would operate _only_ on
.git/config, not any of its included files (just as it
also does not operate on ~/.gitconfig).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
13 years ago
|
|
|
test_expect_success 'include cycles are detected' '
|
|
|
|
|
git init --bare cycle &&
|
|
|
|
|
git -C cycle config include.path cycle &&
|
|
|
|
|
git config -f cycle/cycle include.path config &&
|
|
|
|
|
test_must_fail \
|
|
|
|
|
env GIT_TEST_GETTEXT_POISON=false \
|
|
|
|
|
git -C cycle config --get-all test.value 2>stderr &&
|
|
|
|
|
grep "exceeded maximum include depth" stderr
|
config: add include directive
It can be useful to split your ~/.gitconfig across multiple
files. For example, you might have a "main" file which is
used on many machines, but a small set of per-machine
tweaks. Or you may want to make some of your config public
(e.g., clever aliases) while keeping other data back (e.g.,
your name or other identifying information). Or you may want
to include a number of config options in some subset of your
repos without copying and pasting (e.g., you want to
reference them from the .git/config of participating repos).
This patch introduces an include directive for config files.
It looks like:
[include]
path = /path/to/file
This is syntactically backwards-compatible with existing git
config parsers (i.e., they will see it as another config
entry and ignore it unless you are looking up include.path).
The implementation provides a "git_config_include" callback
which wraps regular config callbacks. Callers can pass it to
git_config_from_file, and it will transparently follow any
include directives, passing all of the discovered options to
the real callback.
Include directives are turned on automatically for "regular"
git config parsing. This includes calls to git_config, as
well as calls to the "git config" program that do not
specify a single file (e.g., using "-f", "--global", etc).
They are not turned on in other cases, including:
1. Parsing of other config-like files, like .gitmodules.
There isn't a real need, and I'd rather be conservative
and avoid unnecessary incompatibility or confusion.
2. Reading single files via "git config". This is for two
reasons:
a. backwards compatibility with scripts looking at
config-like files.
b. inspection of a specific file probably means you
care about just what's in that file, not a general
lookup for "do we have this value anywhere at
all". If that is not the case, the caller can
always specify "--includes".
3. Writing files via "git config"; we want to treat
include.* variables as literal items to be copied (or
modified), and not expand them. So "git config
--unset-all foo.bar" would operate _only_ on
.git/config, not any of its included files (just as it
also does not operate on ~/.gitconfig).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
13 years ago
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_done
|
