2017-03-16 23:29:43 +01:00
|
|
|
#!/bin/sh
|
|
|
|
|
|
2022-09-01 01:17:48 +02:00
|
|
|
test_description='Test with test-tool submodule is-active
|
2017-03-16 23:29:43 +01:00
|
|
|
|
2022-09-01 01:17:48 +02:00
|
|
|
This test verifies that `test-tool submodule is-active` correctly identifies
|
2017-03-16 23:29:43 +01:00
|
|
|
submodules which are "active" and interesting to the user.
|
2022-09-01 01:17:48 +02:00
|
|
|
|
|
|
|
|
This is a unit test of the submodule.c is_submodule_active() function,
|
|
|
|
|
which is also indirectly tested elsewhere.
|
2017-03-16 23:29:43 +01:00
|
|
|
'
|
|
|
|
|
|
|
|
|
|
. ./test-lib.sh
|
|
|
|
|
|
|
|
|
|
test_expect_success 'setup' '
|
|
|
|
|
git init sub &&
|
|
|
|
|
test_commit -C sub initial &&
|
|
|
|
|
git init super &&
|
|
|
|
|
test_commit -C super initial &&
|
|
|
|
|
git -C super submodule add ../sub sub1 &&
|
|
|
|
|
git -C super submodule add ../sub sub2 &&
|
2017-03-17 23:38:05 +01:00
|
|
|
|
|
|
|
|
# Remove submodule.<name>.active entries in order to test in an
|
|
|
|
|
# environment where only URLs are present in the conifg
|
|
|
|
|
git -C super config --unset submodule.sub1.active &&
|
|
|
|
|
git -C super config --unset submodule.sub2.active &&
|
|
|
|
|
|
2017-03-16 23:29:43 +01:00
|
|
|
git -C super commit -a -m "add 2 submodules at sub{1,2}"
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'is-active works with urls' '
|
2022-09-01 01:17:48 +02:00
|
|
|
test-tool -C super submodule is-active sub1 &&
|
|
|
|
|
test-tool -C super submodule is-active sub2 &&
|
2017-03-16 23:29:43 +01:00
|
|
|
|
|
|
|
|
git -C super config --unset submodule.sub1.URL &&
|
2022-09-01 01:17:48 +02:00
|
|
|
test_must_fail test-tool -C super submodule is-active sub1 &&
|
2017-03-16 23:29:43 +01:00
|
|
|
git -C super config submodule.sub1.URL ../sub &&
|
2022-09-01 01:17:48 +02:00
|
|
|
test-tool -C super submodule is-active sub1
|
2017-03-16 23:29:43 +01:00
|
|
|
'
|
|
|
|
|
|
submodule: decouple url and submodule interest
Currently the submodule.<name>.url config option is used to determine if
a given submodule is of interest to the user. This ends up being
cumbersome in a world where we want to have different submodules checked
out in different worktrees or a more generalized mechanism to select
which submodules are of interest.
In a future with worktree support for submodules, there will be multiple
working trees, each of which may only need a subset of the submodules
checked out. The URL (which is where the submodule repository can be
obtained) should not differ between different working trees.
It may also be convenient for users to more easily specify groups of
submodules they are interested in as opposed to running "git submodule
init <path>" on each submodule they want checked out in their working
tree.
To this end two config options are introduced, submodule.active and
submodule.<name>.active. The submodule.active config holds a pathspec
that specifies which submodules should exist in the working tree. The
submodule.<name>.active config is a boolean flag used to indicate if
that particular submodule should exist in the working tree.
Its important to note that submodule.active functions differently than
the other configuration options since it takes a pathspec. This allows
users to adopt at least two new workflows:
1. Submodules can be grouped with a leading directory, such that a
pathspec e.g. 'lib/' would cover all library-ish modules to allow
those who are interested in library-ish modules to set
"submodule.active = lib/" just once to say any and all modules in
'lib/' are interesting.
2. Once the pathspec-attribute feature is invented, users can label
submodules with attributes to group them, so that a broad pathspec
with attribute requirements, e.g. ':(attr:lib)', can be used to say
any and all modules with the 'lib' attribute are interesting.
Since the .gitattributes file, just like the .gitmodules file, is
tracked by the superproject, when a submodule moves in the
superproject tree, the project can adjust which path gets the
attribute in .gitattributes, just like it can adjust which path has
the submodule in .gitmodules.
Neither of these two additional configuration options solve the problem
of wanting different submodules checked out in different worktrees
because multiple worktrees share .git/config. Only once per-worktree
configurations become a reality can this be solved, but this is a
necessary preparatory step for that future.
Given these multiple ways to check if a submodule is of interest, the
more fine-grained submodule.<name>.active option has the highest order
of precedence followed by the pathspec check against submodule.active.
To ensure backwards compatibility, if neither of these options are set,
git falls back to checking the submodule.<name>.url option to determine
if a submodule is interesting.
Signed-off-by: Brandon Williams <bmwill@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-17 23:38:01 +01:00
|
|
|
test_expect_success 'is-active works with submodule.<name>.active config' '
|
|
|
|
|
test_when_finished "git -C super config --unset submodule.sub1.active" &&
|
|
|
|
|
test_when_finished "git -C super config submodule.sub1.URL ../sub" &&
|
|
|
|
|
|
|
|
|
|
git -C super config --bool submodule.sub1.active "false" &&
|
2022-09-01 01:17:48 +02:00
|
|
|
test_must_fail test-tool -C super submodule is-active sub1 &&
|
submodule: decouple url and submodule interest
Currently the submodule.<name>.url config option is used to determine if
a given submodule is of interest to the user. This ends up being
cumbersome in a world where we want to have different submodules checked
out in different worktrees or a more generalized mechanism to select
which submodules are of interest.
In a future with worktree support for submodules, there will be multiple
working trees, each of which may only need a subset of the submodules
checked out. The URL (which is where the submodule repository can be
obtained) should not differ between different working trees.
It may also be convenient for users to more easily specify groups of
submodules they are interested in as opposed to running "git submodule
init <path>" on each submodule they want checked out in their working
tree.
To this end two config options are introduced, submodule.active and
submodule.<name>.active. The submodule.active config holds a pathspec
that specifies which submodules should exist in the working tree. The
submodule.<name>.active config is a boolean flag used to indicate if
that particular submodule should exist in the working tree.
Its important to note that submodule.active functions differently than
the other configuration options since it takes a pathspec. This allows
users to adopt at least two new workflows:
1. Submodules can be grouped with a leading directory, such that a
pathspec e.g. 'lib/' would cover all library-ish modules to allow
those who are interested in library-ish modules to set
"submodule.active = lib/" just once to say any and all modules in
'lib/' are interesting.
2. Once the pathspec-attribute feature is invented, users can label
submodules with attributes to group them, so that a broad pathspec
with attribute requirements, e.g. ':(attr:lib)', can be used to say
any and all modules with the 'lib' attribute are interesting.
Since the .gitattributes file, just like the .gitmodules file, is
tracked by the superproject, when a submodule moves in the
superproject tree, the project can adjust which path gets the
attribute in .gitattributes, just like it can adjust which path has
the submodule in .gitmodules.
Neither of these two additional configuration options solve the problem
of wanting different submodules checked out in different worktrees
because multiple worktrees share .git/config. Only once per-worktree
configurations become a reality can this be solved, but this is a
necessary preparatory step for that future.
Given these multiple ways to check if a submodule is of interest, the
more fine-grained submodule.<name>.active option has the highest order
of precedence followed by the pathspec check against submodule.active.
To ensure backwards compatibility, if neither of these options are set,
git falls back to checking the submodule.<name>.url option to determine
if a submodule is interesting.
Signed-off-by: Brandon Williams <bmwill@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-17 23:38:01 +01:00
|
|
|
|
|
|
|
|
git -C super config --bool submodule.sub1.active "true" &&
|
|
|
|
|
git -C super config --unset submodule.sub1.URL &&
|
2022-09-01 01:17:48 +02:00
|
|
|
test-tool -C super submodule is-active sub1
|
submodule: decouple url and submodule interest
Currently the submodule.<name>.url config option is used to determine if
a given submodule is of interest to the user. This ends up being
cumbersome in a world where we want to have different submodules checked
out in different worktrees or a more generalized mechanism to select
which submodules are of interest.
In a future with worktree support for submodules, there will be multiple
working trees, each of which may only need a subset of the submodules
checked out. The URL (which is where the submodule repository can be
obtained) should not differ between different working trees.
It may also be convenient for users to more easily specify groups of
submodules they are interested in as opposed to running "git submodule
init <path>" on each submodule they want checked out in their working
tree.
To this end two config options are introduced, submodule.active and
submodule.<name>.active. The submodule.active config holds a pathspec
that specifies which submodules should exist in the working tree. The
submodule.<name>.active config is a boolean flag used to indicate if
that particular submodule should exist in the working tree.
Its important to note that submodule.active functions differently than
the other configuration options since it takes a pathspec. This allows
users to adopt at least two new workflows:
1. Submodules can be grouped with a leading directory, such that a
pathspec e.g. 'lib/' would cover all library-ish modules to allow
those who are interested in library-ish modules to set
"submodule.active = lib/" just once to say any and all modules in
'lib/' are interesting.
2. Once the pathspec-attribute feature is invented, users can label
submodules with attributes to group them, so that a broad pathspec
with attribute requirements, e.g. ':(attr:lib)', can be used to say
any and all modules with the 'lib' attribute are interesting.
Since the .gitattributes file, just like the .gitmodules file, is
tracked by the superproject, when a submodule moves in the
superproject tree, the project can adjust which path gets the
attribute in .gitattributes, just like it can adjust which path has
the submodule in .gitmodules.
Neither of these two additional configuration options solve the problem
of wanting different submodules checked out in different worktrees
because multiple worktrees share .git/config. Only once per-worktree
configurations become a reality can this be solved, but this is a
necessary preparatory step for that future.
Given these multiple ways to check if a submodule is of interest, the
more fine-grained submodule.<name>.active option has the highest order
of precedence followed by the pathspec check against submodule.active.
To ensure backwards compatibility, if neither of these options are set,
git falls back to checking the submodule.<name>.url option to determine
if a submodule is interesting.
Signed-off-by: Brandon Williams <bmwill@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-17 23:38:01 +01:00
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'is-active works with basic submodule.active config' '
|
|
|
|
|
test_when_finished "git -C super config submodule.sub1.URL ../sub" &&
|
|
|
|
|
test_when_finished "git -C super config --unset-all submodule.active" &&
|
|
|
|
|
|
|
|
|
|
git -C super config --add submodule.active "." &&
|
|
|
|
|
git -C super config --unset submodule.sub1.URL &&
|
|
|
|
|
|
2022-09-01 01:17:48 +02:00
|
|
|
test-tool -C super submodule is-active sub1 &&
|
|
|
|
|
test-tool -C super submodule is-active sub2
|
submodule: decouple url and submodule interest
Currently the submodule.<name>.url config option is used to determine if
a given submodule is of interest to the user. This ends up being
cumbersome in a world where we want to have different submodules checked
out in different worktrees or a more generalized mechanism to select
which submodules are of interest.
In a future with worktree support for submodules, there will be multiple
working trees, each of which may only need a subset of the submodules
checked out. The URL (which is where the submodule repository can be
obtained) should not differ between different working trees.
It may also be convenient for users to more easily specify groups of
submodules they are interested in as opposed to running "git submodule
init <path>" on each submodule they want checked out in their working
tree.
To this end two config options are introduced, submodule.active and
submodule.<name>.active. The submodule.active config holds a pathspec
that specifies which submodules should exist in the working tree. The
submodule.<name>.active config is a boolean flag used to indicate if
that particular submodule should exist in the working tree.
Its important to note that submodule.active functions differently than
the other configuration options since it takes a pathspec. This allows
users to adopt at least two new workflows:
1. Submodules can be grouped with a leading directory, such that a
pathspec e.g. 'lib/' would cover all library-ish modules to allow
those who are interested in library-ish modules to set
"submodule.active = lib/" just once to say any and all modules in
'lib/' are interesting.
2. Once the pathspec-attribute feature is invented, users can label
submodules with attributes to group them, so that a broad pathspec
with attribute requirements, e.g. ':(attr:lib)', can be used to say
any and all modules with the 'lib' attribute are interesting.
Since the .gitattributes file, just like the .gitmodules file, is
tracked by the superproject, when a submodule moves in the
superproject tree, the project can adjust which path gets the
attribute in .gitattributes, just like it can adjust which path has
the submodule in .gitmodules.
Neither of these two additional configuration options solve the problem
of wanting different submodules checked out in different worktrees
because multiple worktrees share .git/config. Only once per-worktree
configurations become a reality can this be solved, but this is a
necessary preparatory step for that future.
Given these multiple ways to check if a submodule is of interest, the
more fine-grained submodule.<name>.active option has the highest order
of precedence followed by the pathspec check against submodule.active.
To ensure backwards compatibility, if neither of these options are set,
git falls back to checking the submodule.<name>.url option to determine
if a submodule is interesting.
Signed-off-by: Brandon Williams <bmwill@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-17 23:38:01 +01:00
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'is-active correctly works with paths that are not submodules' '
|
|
|
|
|
test_when_finished "git -C super config --unset-all submodule.active" &&
|
|
|
|
|
|
2022-09-01 01:17:48 +02:00
|
|
|
test_must_fail test-tool -C super submodule is-active not-a-submodule &&
|
submodule: decouple url and submodule interest
Currently the submodule.<name>.url config option is used to determine if
a given submodule is of interest to the user. This ends up being
cumbersome in a world where we want to have different submodules checked
out in different worktrees or a more generalized mechanism to select
which submodules are of interest.
In a future with worktree support for submodules, there will be multiple
working trees, each of which may only need a subset of the submodules
checked out. The URL (which is where the submodule repository can be
obtained) should not differ between different working trees.
It may also be convenient for users to more easily specify groups of
submodules they are interested in as opposed to running "git submodule
init <path>" on each submodule they want checked out in their working
tree.
To this end two config options are introduced, submodule.active and
submodule.<name>.active. The submodule.active config holds a pathspec
that specifies which submodules should exist in the working tree. The
submodule.<name>.active config is a boolean flag used to indicate if
that particular submodule should exist in the working tree.
Its important to note that submodule.active functions differently than
the other configuration options since it takes a pathspec. This allows
users to adopt at least two new workflows:
1. Submodules can be grouped with a leading directory, such that a
pathspec e.g. 'lib/' would cover all library-ish modules to allow
those who are interested in library-ish modules to set
"submodule.active = lib/" just once to say any and all modules in
'lib/' are interesting.
2. Once the pathspec-attribute feature is invented, users can label
submodules with attributes to group them, so that a broad pathspec
with attribute requirements, e.g. ':(attr:lib)', can be used to say
any and all modules with the 'lib' attribute are interesting.
Since the .gitattributes file, just like the .gitmodules file, is
tracked by the superproject, when a submodule moves in the
superproject tree, the project can adjust which path gets the
attribute in .gitattributes, just like it can adjust which path has
the submodule in .gitmodules.
Neither of these two additional configuration options solve the problem
of wanting different submodules checked out in different worktrees
because multiple worktrees share .git/config. Only once per-worktree
configurations become a reality can this be solved, but this is a
necessary preparatory step for that future.
Given these multiple ways to check if a submodule is of interest, the
more fine-grained submodule.<name>.active option has the highest order
of precedence followed by the pathspec check against submodule.active.
To ensure backwards compatibility, if neither of these options are set,
git falls back to checking the submodule.<name>.url option to determine
if a submodule is interesting.
Signed-off-by: Brandon Williams <bmwill@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-17 23:38:01 +01:00
|
|
|
|
|
|
|
|
git -C super config --add submodule.active "." &&
|
2022-09-01 01:17:48 +02:00
|
|
|
test_must_fail test-tool -C super submodule is-active not-a-submodule
|
submodule: decouple url and submodule interest
Currently the submodule.<name>.url config option is used to determine if
a given submodule is of interest to the user. This ends up being
cumbersome in a world where we want to have different submodules checked
out in different worktrees or a more generalized mechanism to select
which submodules are of interest.
In a future with worktree support for submodules, there will be multiple
working trees, each of which may only need a subset of the submodules
checked out. The URL (which is where the submodule repository can be
obtained) should not differ between different working trees.
It may also be convenient for users to more easily specify groups of
submodules they are interested in as opposed to running "git submodule
init <path>" on each submodule they want checked out in their working
tree.
To this end two config options are introduced, submodule.active and
submodule.<name>.active. The submodule.active config holds a pathspec
that specifies which submodules should exist in the working tree. The
submodule.<name>.active config is a boolean flag used to indicate if
that particular submodule should exist in the working tree.
Its important to note that submodule.active functions differently than
the other configuration options since it takes a pathspec. This allows
users to adopt at least two new workflows:
1. Submodules can be grouped with a leading directory, such that a
pathspec e.g. 'lib/' would cover all library-ish modules to allow
those who are interested in library-ish modules to set
"submodule.active = lib/" just once to say any and all modules in
'lib/' are interesting.
2. Once the pathspec-attribute feature is invented, users can label
submodules with attributes to group them, so that a broad pathspec
with attribute requirements, e.g. ':(attr:lib)', can be used to say
any and all modules with the 'lib' attribute are interesting.
Since the .gitattributes file, just like the .gitmodules file, is
tracked by the superproject, when a submodule moves in the
superproject tree, the project can adjust which path gets the
attribute in .gitattributes, just like it can adjust which path has
the submodule in .gitmodules.
Neither of these two additional configuration options solve the problem
of wanting different submodules checked out in different worktrees
because multiple worktrees share .git/config. Only once per-worktree
configurations become a reality can this be solved, but this is a
necessary preparatory step for that future.
Given these multiple ways to check if a submodule is of interest, the
more fine-grained submodule.<name>.active option has the highest order
of precedence followed by the pathspec check against submodule.active.
To ensure backwards compatibility, if neither of these options are set,
git falls back to checking the submodule.<name>.url option to determine
if a submodule is interesting.
Signed-off-by: Brandon Williams <bmwill@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-17 23:38:01 +01:00
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'is-active works with exclusions in submodule.active config' '
|
|
|
|
|
test_when_finished "git -C super config --unset-all submodule.active" &&
|
|
|
|
|
|
|
|
|
|
git -C super config --add submodule.active "." &&
|
|
|
|
|
git -C super config --add submodule.active ":(exclude)sub1" &&
|
|
|
|
|
|
2022-09-01 01:17:48 +02:00
|
|
|
test_must_fail test-tool -C super submodule is-active sub1 &&
|
|
|
|
|
test-tool -C super submodule is-active sub2
|
submodule: decouple url and submodule interest
Currently the submodule.<name>.url config option is used to determine if
a given submodule is of interest to the user. This ends up being
cumbersome in a world where we want to have different submodules checked
out in different worktrees or a more generalized mechanism to select
which submodules are of interest.
In a future with worktree support for submodules, there will be multiple
working trees, each of which may only need a subset of the submodules
checked out. The URL (which is where the submodule repository can be
obtained) should not differ between different working trees.
It may also be convenient for users to more easily specify groups of
submodules they are interested in as opposed to running "git submodule
init <path>" on each submodule they want checked out in their working
tree.
To this end two config options are introduced, submodule.active and
submodule.<name>.active. The submodule.active config holds a pathspec
that specifies which submodules should exist in the working tree. The
submodule.<name>.active config is a boolean flag used to indicate if
that particular submodule should exist in the working tree.
Its important to note that submodule.active functions differently than
the other configuration options since it takes a pathspec. This allows
users to adopt at least two new workflows:
1. Submodules can be grouped with a leading directory, such that a
pathspec e.g. 'lib/' would cover all library-ish modules to allow
those who are interested in library-ish modules to set
"submodule.active = lib/" just once to say any and all modules in
'lib/' are interesting.
2. Once the pathspec-attribute feature is invented, users can label
submodules with attributes to group them, so that a broad pathspec
with attribute requirements, e.g. ':(attr:lib)', can be used to say
any and all modules with the 'lib' attribute are interesting.
Since the .gitattributes file, just like the .gitmodules file, is
tracked by the superproject, when a submodule moves in the
superproject tree, the project can adjust which path gets the
attribute in .gitattributes, just like it can adjust which path has
the submodule in .gitmodules.
Neither of these two additional configuration options solve the problem
of wanting different submodules checked out in different worktrees
because multiple worktrees share .git/config. Only once per-worktree
configurations become a reality can this be solved, but this is a
necessary preparatory step for that future.
Given these multiple ways to check if a submodule is of interest, the
more fine-grained submodule.<name>.active option has the highest order
of precedence followed by the pathspec check against submodule.active.
To ensure backwards compatibility, if neither of these options are set,
git falls back to checking the submodule.<name>.url option to determine
if a submodule is interesting.
Signed-off-by: Brandon Williams <bmwill@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-17 23:38:01 +01:00
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'is-active with submodule.active and submodule.<name>.active' '
|
|
|
|
|
test_when_finished "git -C super config --unset-all submodule.active" &&
|
|
|
|
|
test_when_finished "git -C super config --unset submodule.sub1.active" &&
|
|
|
|
|
test_when_finished "git -C super config --unset submodule.sub2.active" &&
|
|
|
|
|
|
|
|
|
|
git -C super config --add submodule.active "sub1" &&
|
|
|
|
|
git -C super config --bool submodule.sub1.active "false" &&
|
|
|
|
|
git -C super config --bool submodule.sub2.active "true" &&
|
|
|
|
|
|
2022-09-01 01:17:48 +02:00
|
|
|
test_must_fail test-tool -C super submodule is-active sub1 &&
|
|
|
|
|
test-tool -C super submodule is-active sub2
|
submodule: decouple url and submodule interest
Currently the submodule.<name>.url config option is used to determine if
a given submodule is of interest to the user. This ends up being
cumbersome in a world where we want to have different submodules checked
out in different worktrees or a more generalized mechanism to select
which submodules are of interest.
In a future with worktree support for submodules, there will be multiple
working trees, each of which may only need a subset of the submodules
checked out. The URL (which is where the submodule repository can be
obtained) should not differ between different working trees.
It may also be convenient for users to more easily specify groups of
submodules they are interested in as opposed to running "git submodule
init <path>" on each submodule they want checked out in their working
tree.
To this end two config options are introduced, submodule.active and
submodule.<name>.active. The submodule.active config holds a pathspec
that specifies which submodules should exist in the working tree. The
submodule.<name>.active config is a boolean flag used to indicate if
that particular submodule should exist in the working tree.
Its important to note that submodule.active functions differently than
the other configuration options since it takes a pathspec. This allows
users to adopt at least two new workflows:
1. Submodules can be grouped with a leading directory, such that a
pathspec e.g. 'lib/' would cover all library-ish modules to allow
those who are interested in library-ish modules to set
"submodule.active = lib/" just once to say any and all modules in
'lib/' are interesting.
2. Once the pathspec-attribute feature is invented, users can label
submodules with attributes to group them, so that a broad pathspec
with attribute requirements, e.g. ':(attr:lib)', can be used to say
any and all modules with the 'lib' attribute are interesting.
Since the .gitattributes file, just like the .gitmodules file, is
tracked by the superproject, when a submodule moves in the
superproject tree, the project can adjust which path gets the
attribute in .gitattributes, just like it can adjust which path has
the submodule in .gitmodules.
Neither of these two additional configuration options solve the problem
of wanting different submodules checked out in different worktrees
because multiple worktrees share .git/config. Only once per-worktree
configurations become a reality can this be solved, but this is a
necessary preparatory step for that future.
Given these multiple ways to check if a submodule is of interest, the
more fine-grained submodule.<name>.active option has the highest order
of precedence followed by the pathspec check against submodule.active.
To ensure backwards compatibility, if neither of these options are set,
git falls back to checking the submodule.<name>.url option to determine
if a submodule is interesting.
Signed-off-by: Brandon Williams <bmwill@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-17 23:38:01 +01:00
|
|
|
'
|
|
|
|
|
|
2017-03-17 23:38:05 +01:00
|
|
|
test_expect_success 'is-active, submodule.active and submodule add' '
|
|
|
|
|
test_when_finished "rm -rf super2" &&
|
|
|
|
|
git init super2 &&
|
|
|
|
|
test_commit -C super2 initial &&
|
|
|
|
|
git -C super2 config --add submodule.active "sub*" &&
|
|
|
|
|
|
|
|
|
|
# submodule add should only add submodule.<name>.active
|
|
|
|
|
# to the config if not matched by the pathspec
|
|
|
|
|
git -C super2 submodule add ../sub sub1 &&
|
|
|
|
|
test_must_fail git -C super2 config --get submodule.sub1.active &&
|
|
|
|
|
|
|
|
|
|
git -C super2 submodule add ../sub mod &&
|
|
|
|
|
git -C super2 config --get submodule.mod.active
|
|
|
|
|
'
|
|
|
|
|
|
2017-03-16 23:29:43 +01:00
|
|
|
test_done
|