git-commit-vandalism/t/lib-submodule-update.sh

1097 lines
37 KiB
Bash
Raw Normal View History

submodules: add the lib-submodule-update.sh test library Add this test library to simplify covering all combinations of submodule update scenarios without having to add those to a test of each work tree manipulating command over and over again. The functions test_submodule_switch() and test_submodule_forced_switch() are intended to be called from a test script with a single argument. This argument is either a work tree manipulating command (including any command line options) or a function (when more than a single git command is needed to switch work trees from the current HEAD to another commit). This command (or function) is passed a target branch as argument. The two new functions check that each submodule transition is handled as expected, which currently means that submodule work trees are not affected until "git submodule update" is called. The "forced" variant is for commands using their '-f' or '--hard' option and expects them to overwrite local modifications as a result. Each of these two functions contains 14 tests_expect_* calls. Calling one of these test functions the first time creates a repository named "submodule_update_repo". At first it contains two files, then a single submodule is added in another commit followed by commits covering all relevant submodule modifications. This repository is newly cloned into the "submodule_update" for each test_expect_* to avoid interference between different parts of the test functions (some to-be-tested commands also manipulate refs along with the work tree, e.g. "git reset"). Follow-up commits will then call these two test functions for all work tree manipulating commands (with a combination of all their options relevant to what they do with the work tree) making sure they work as expected. Later this test library will be extended to cover merges resulting in conflicts too. Also it is intended to be easily extendable for the recursive update functionality, where even more combinations of submodule modifications have to be tested for. This version documents two bugs in current Git with expected failures: *) When a submodule is replaced with a tracked file of the same name the submodule work tree including any local modifications (and even the whole history if it uses a .git directory instead of a gitfile!) is silently removed. *) Forced work tree updates happily manipulate files in the directory of a submodule that has just been removed in the superproject (but is of course still present in the work tree due to the way submodules are currently handled). This becomes dangerous when files in the submodule directory are overwritten by files from the new superproject commit, as any modifications to the submodule files will be lost) and is expected to also destroy history in the - admittedly unlikely case - the new commit adds a file named ".git" to the submodule directory. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-07-01 23:24:14 +02:00
# Create a submodule layout used for all tests below.
#
# The following use cases are covered:
# - New submodule (no_submodule => add_sub1)
# - Removed submodule (add_sub1 => remove_sub1)
# - Updated submodule (add_sub1 => modify_sub1)
# - Updated submodule recursively (add_nested_sub => modify_sub1_recursively)
submodules: add the lib-submodule-update.sh test library Add this test library to simplify covering all combinations of submodule update scenarios without having to add those to a test of each work tree manipulating command over and over again. The functions test_submodule_switch() and test_submodule_forced_switch() are intended to be called from a test script with a single argument. This argument is either a work tree manipulating command (including any command line options) or a function (when more than a single git command is needed to switch work trees from the current HEAD to another commit). This command (or function) is passed a target branch as argument. The two new functions check that each submodule transition is handled as expected, which currently means that submodule work trees are not affected until "git submodule update" is called. The "forced" variant is for commands using their '-f' or '--hard' option and expects them to overwrite local modifications as a result. Each of these two functions contains 14 tests_expect_* calls. Calling one of these test functions the first time creates a repository named "submodule_update_repo". At first it contains two files, then a single submodule is added in another commit followed by commits covering all relevant submodule modifications. This repository is newly cloned into the "submodule_update" for each test_expect_* to avoid interference between different parts of the test functions (some to-be-tested commands also manipulate refs along with the work tree, e.g. "git reset"). Follow-up commits will then call these two test functions for all work tree manipulating commands (with a combination of all their options relevant to what they do with the work tree) making sure they work as expected. Later this test library will be extended to cover merges resulting in conflicts too. Also it is intended to be easily extendable for the recursive update functionality, where even more combinations of submodule modifications have to be tested for. This version documents two bugs in current Git with expected failures: *) When a submodule is replaced with a tracked file of the same name the submodule work tree including any local modifications (and even the whole history if it uses a .git directory instead of a gitfile!) is silently removed. *) Forced work tree updates happily manipulate files in the directory of a submodule that has just been removed in the superproject (but is of course still present in the work tree due to the way submodules are currently handled). This becomes dangerous when files in the submodule directory are overwritten by files from the new superproject commit, as any modifications to the submodule files will be lost) and is expected to also destroy history in the - admittedly unlikely case - the new commit adds a file named ".git" to the submodule directory. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-07-01 23:24:14 +02:00
# - Submodule updated to invalid commit (add_sub1 => invalid_sub1)
# - Submodule updated from invalid commit (invalid_sub1 => valid_sub1)
# - Submodule replaced by tracked files in directory (add_sub1 =>
# replace_sub1_with_directory)
# - Directory containing tracked files replaced by submodule
# (replace_sub1_with_directory => replace_directory_with_sub1)
# - Submodule replaced by tracked file with the same name (add_sub1 =>
# replace_sub1_with_file)
# - Tracked file replaced by submodule (replace_sub1_with_file =>
# replace_file_with_sub1)
#
# ----O
# / ^
# / remove_sub1
# /
# add_sub1 /-------O---------O--------O modify_sub1_recursively
# | / ^ add_nested_sub
# | / modify_sub1
# v/
# O------O-----------O---------O
# ^ \ ^ replace_directory_with_sub1
# | \ replace_sub1_with_directory
# no_submodule \
# --------O---------O
# \ ^ replace_file_with_sub1
# \ replace_sub1_with_file
# \
# ----O---------O
# ^ valid_sub1
# invalid_sub1
submodules: add the lib-submodule-update.sh test library Add this test library to simplify covering all combinations of submodule update scenarios without having to add those to a test of each work tree manipulating command over and over again. The functions test_submodule_switch() and test_submodule_forced_switch() are intended to be called from a test script with a single argument. This argument is either a work tree manipulating command (including any command line options) or a function (when more than a single git command is needed to switch work trees from the current HEAD to another commit). This command (or function) is passed a target branch as argument. The two new functions check that each submodule transition is handled as expected, which currently means that submodule work trees are not affected until "git submodule update" is called. The "forced" variant is for commands using their '-f' or '--hard' option and expects them to overwrite local modifications as a result. Each of these two functions contains 14 tests_expect_* calls. Calling one of these test functions the first time creates a repository named "submodule_update_repo". At first it contains two files, then a single submodule is added in another commit followed by commits covering all relevant submodule modifications. This repository is newly cloned into the "submodule_update" for each test_expect_* to avoid interference between different parts of the test functions (some to-be-tested commands also manipulate refs along with the work tree, e.g. "git reset"). Follow-up commits will then call these two test functions for all work tree manipulating commands (with a combination of all their options relevant to what they do with the work tree) making sure they work as expected. Later this test library will be extended to cover merges resulting in conflicts too. Also it is intended to be easily extendable for the recursive update functionality, where even more combinations of submodule modifications have to be tested for. This version documents two bugs in current Git with expected failures: *) When a submodule is replaced with a tracked file of the same name the submodule work tree including any local modifications (and even the whole history if it uses a .git directory instead of a gitfile!) is silently removed. *) Forced work tree updates happily manipulate files in the directory of a submodule that has just been removed in the superproject (but is of course still present in the work tree due to the way submodules are currently handled). This becomes dangerous when files in the submodule directory are overwritten by files from the new superproject commit, as any modifications to the submodule files will be lost) and is expected to also destroy history in the - admittedly unlikely case - the new commit adds a file named ".git" to the submodule directory. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-07-01 23:24:14 +02:00
#
submodules: add the lib-submodule-update.sh test library Add this test library to simplify covering all combinations of submodule update scenarios without having to add those to a test of each work tree manipulating command over and over again. The functions test_submodule_switch() and test_submodule_forced_switch() are intended to be called from a test script with a single argument. This argument is either a work tree manipulating command (including any command line options) or a function (when more than a single git command is needed to switch work trees from the current HEAD to another commit). This command (or function) is passed a target branch as argument. The two new functions check that each submodule transition is handled as expected, which currently means that submodule work trees are not affected until "git submodule update" is called. The "forced" variant is for commands using their '-f' or '--hard' option and expects them to overwrite local modifications as a result. Each of these two functions contains 14 tests_expect_* calls. Calling one of these test functions the first time creates a repository named "submodule_update_repo". At first it contains two files, then a single submodule is added in another commit followed by commits covering all relevant submodule modifications. This repository is newly cloned into the "submodule_update" for each test_expect_* to avoid interference between different parts of the test functions (some to-be-tested commands also manipulate refs along with the work tree, e.g. "git reset"). Follow-up commits will then call these two test functions for all work tree manipulating commands (with a combination of all their options relevant to what they do with the work tree) making sure they work as expected. Later this test library will be extended to cover merges resulting in conflicts too. Also it is intended to be easily extendable for the recursive update functionality, where even more combinations of submodule modifications have to be tested for. This version documents two bugs in current Git with expected failures: *) When a submodule is replaced with a tracked file of the same name the submodule work tree including any local modifications (and even the whole history if it uses a .git directory instead of a gitfile!) is silently removed. *) Forced work tree updates happily manipulate files in the directory of a submodule that has just been removed in the superproject (but is of course still present in the work tree due to the way submodules are currently handled). This becomes dangerous when files in the submodule directory are overwritten by files from the new superproject commit, as any modifications to the submodule files will be lost) and is expected to also destroy history in the - admittedly unlikely case - the new commit adds a file named ".git" to the submodule directory. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-07-01 23:24:14 +02:00
create_lib_submodule_repo () {
git init submodule_update_sub1 &&
(
cd submodule_update_sub1 &&
echo "expect" >>.gitignore &&
echo "actual" >>.gitignore &&
echo "x" >file1 &&
echo "y" >file2 &&
git add .gitignore file1 file2 &&
git commit -m "Base inside first submodule" &&
git branch "no_submodule"
) &&
git init submodule_update_sub2 &&
(
cd submodule_update_sub2
echo "expect" >>.gitignore &&
echo "actual" >>.gitignore &&
echo "x" >file1 &&
echo "y" >file2 &&
git add .gitignore file1 file2 &&
git commit -m "nested submodule base" &&
git branch "no_submodule"
) &&
submodules: add the lib-submodule-update.sh test library Add this test library to simplify covering all combinations of submodule update scenarios without having to add those to a test of each work tree manipulating command over and over again. The functions test_submodule_switch() and test_submodule_forced_switch() are intended to be called from a test script with a single argument. This argument is either a work tree manipulating command (including any command line options) or a function (when more than a single git command is needed to switch work trees from the current HEAD to another commit). This command (or function) is passed a target branch as argument. The two new functions check that each submodule transition is handled as expected, which currently means that submodule work trees are not affected until "git submodule update" is called. The "forced" variant is for commands using their '-f' or '--hard' option and expects them to overwrite local modifications as a result. Each of these two functions contains 14 tests_expect_* calls. Calling one of these test functions the first time creates a repository named "submodule_update_repo". At first it contains two files, then a single submodule is added in another commit followed by commits covering all relevant submodule modifications. This repository is newly cloned into the "submodule_update" for each test_expect_* to avoid interference between different parts of the test functions (some to-be-tested commands also manipulate refs along with the work tree, e.g. "git reset"). Follow-up commits will then call these two test functions for all work tree manipulating commands (with a combination of all their options relevant to what they do with the work tree) making sure they work as expected. Later this test library will be extended to cover merges resulting in conflicts too. Also it is intended to be easily extendable for the recursive update functionality, where even more combinations of submodule modifications have to be tested for. This version documents two bugs in current Git with expected failures: *) When a submodule is replaced with a tracked file of the same name the submodule work tree including any local modifications (and even the whole history if it uses a .git directory instead of a gitfile!) is silently removed. *) Forced work tree updates happily manipulate files in the directory of a submodule that has just been removed in the superproject (but is of course still present in the work tree due to the way submodules are currently handled). This becomes dangerous when files in the submodule directory are overwritten by files from the new superproject commit, as any modifications to the submodule files will be lost) and is expected to also destroy history in the - admittedly unlikely case - the new commit adds a file named ".git" to the submodule directory. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-07-01 23:24:14 +02:00
git init submodule_update_repo &&
(
cd submodule_update_repo &&
echo "expect" >>.gitignore &&
echo "actual" >>.gitignore &&
echo "x" >file1 &&
echo "y" >file2 &&
git add .gitignore file1 file2 &&
git commit -m "Base" &&
git branch "no_submodule" &&
git checkout -b "add_sub1" &&
git submodule add ../submodule_update_sub1 sub1 &&
git submodule add ../submodule_update_sub1 uninitialized_sub &&
submodules: add the lib-submodule-update.sh test library Add this test library to simplify covering all combinations of submodule update scenarios without having to add those to a test of each work tree manipulating command over and over again. The functions test_submodule_switch() and test_submodule_forced_switch() are intended to be called from a test script with a single argument. This argument is either a work tree manipulating command (including any command line options) or a function (when more than a single git command is needed to switch work trees from the current HEAD to another commit). This command (or function) is passed a target branch as argument. The two new functions check that each submodule transition is handled as expected, which currently means that submodule work trees are not affected until "git submodule update" is called. The "forced" variant is for commands using their '-f' or '--hard' option and expects them to overwrite local modifications as a result. Each of these two functions contains 14 tests_expect_* calls. Calling one of these test functions the first time creates a repository named "submodule_update_repo". At first it contains two files, then a single submodule is added in another commit followed by commits covering all relevant submodule modifications. This repository is newly cloned into the "submodule_update" for each test_expect_* to avoid interference between different parts of the test functions (some to-be-tested commands also manipulate refs along with the work tree, e.g. "git reset"). Follow-up commits will then call these two test functions for all work tree manipulating commands (with a combination of all their options relevant to what they do with the work tree) making sure they work as expected. Later this test library will be extended to cover merges resulting in conflicts too. Also it is intended to be easily extendable for the recursive update functionality, where even more combinations of submodule modifications have to be tested for. This version documents two bugs in current Git with expected failures: *) When a submodule is replaced with a tracked file of the same name the submodule work tree including any local modifications (and even the whole history if it uses a .git directory instead of a gitfile!) is silently removed. *) Forced work tree updates happily manipulate files in the directory of a submodule that has just been removed in the superproject (but is of course still present in the work tree due to the way submodules are currently handled). This becomes dangerous when files in the submodule directory are overwritten by files from the new superproject commit, as any modifications to the submodule files will be lost) and is expected to also destroy history in the - admittedly unlikely case - the new commit adds a file named ".git" to the submodule directory. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-07-01 23:24:14 +02:00
git config -f .gitmodules submodule.sub1.ignore all &&
git config submodule.sub1.ignore all &&
git add .gitmodules &&
git commit -m "Add sub1" &&
git checkout -b remove_sub1 add_sub1 &&
submodules: add the lib-submodule-update.sh test library Add this test library to simplify covering all combinations of submodule update scenarios without having to add those to a test of each work tree manipulating command over and over again. The functions test_submodule_switch() and test_submodule_forced_switch() are intended to be called from a test script with a single argument. This argument is either a work tree manipulating command (including any command line options) or a function (when more than a single git command is needed to switch work trees from the current HEAD to another commit). This command (or function) is passed a target branch as argument. The two new functions check that each submodule transition is handled as expected, which currently means that submodule work trees are not affected until "git submodule update" is called. The "forced" variant is for commands using their '-f' or '--hard' option and expects them to overwrite local modifications as a result. Each of these two functions contains 14 tests_expect_* calls. Calling one of these test functions the first time creates a repository named "submodule_update_repo". At first it contains two files, then a single submodule is added in another commit followed by commits covering all relevant submodule modifications. This repository is newly cloned into the "submodule_update" for each test_expect_* to avoid interference between different parts of the test functions (some to-be-tested commands also manipulate refs along with the work tree, e.g. "git reset"). Follow-up commits will then call these two test functions for all work tree manipulating commands (with a combination of all their options relevant to what they do with the work tree) making sure they work as expected. Later this test library will be extended to cover merges resulting in conflicts too. Also it is intended to be easily extendable for the recursive update functionality, where even more combinations of submodule modifications have to be tested for. This version documents two bugs in current Git with expected failures: *) When a submodule is replaced with a tracked file of the same name the submodule work tree including any local modifications (and even the whole history if it uses a .git directory instead of a gitfile!) is silently removed. *) Forced work tree updates happily manipulate files in the directory of a submodule that has just been removed in the superproject (but is of course still present in the work tree due to the way submodules are currently handled). This becomes dangerous when files in the submodule directory are overwritten by files from the new superproject commit, as any modifications to the submodule files will be lost) and is expected to also destroy history in the - admittedly unlikely case - the new commit adds a file named ".git" to the submodule directory. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-07-01 23:24:14 +02:00
git revert HEAD &&
git checkout -b modify_sub1 add_sub1 &&
submodules: add the lib-submodule-update.sh test library Add this test library to simplify covering all combinations of submodule update scenarios without having to add those to a test of each work tree manipulating command over and over again. The functions test_submodule_switch() and test_submodule_forced_switch() are intended to be called from a test script with a single argument. This argument is either a work tree manipulating command (including any command line options) or a function (when more than a single git command is needed to switch work trees from the current HEAD to another commit). This command (or function) is passed a target branch as argument. The two new functions check that each submodule transition is handled as expected, which currently means that submodule work trees are not affected until "git submodule update" is called. The "forced" variant is for commands using their '-f' or '--hard' option and expects them to overwrite local modifications as a result. Each of these two functions contains 14 tests_expect_* calls. Calling one of these test functions the first time creates a repository named "submodule_update_repo". At first it contains two files, then a single submodule is added in another commit followed by commits covering all relevant submodule modifications. This repository is newly cloned into the "submodule_update" for each test_expect_* to avoid interference between different parts of the test functions (some to-be-tested commands also manipulate refs along with the work tree, e.g. "git reset"). Follow-up commits will then call these two test functions for all work tree manipulating commands (with a combination of all their options relevant to what they do with the work tree) making sure they work as expected. Later this test library will be extended to cover merges resulting in conflicts too. Also it is intended to be easily extendable for the recursive update functionality, where even more combinations of submodule modifications have to be tested for. This version documents two bugs in current Git with expected failures: *) When a submodule is replaced with a tracked file of the same name the submodule work tree including any local modifications (and even the whole history if it uses a .git directory instead of a gitfile!) is silently removed. *) Forced work tree updates happily manipulate files in the directory of a submodule that has just been removed in the superproject (but is of course still present in the work tree due to the way submodules are currently handled). This becomes dangerous when files in the submodule directory are overwritten by files from the new superproject commit, as any modifications to the submodule files will be lost) and is expected to also destroy history in the - admittedly unlikely case - the new commit adds a file named ".git" to the submodule directory. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-07-01 23:24:14 +02:00
git submodule update &&
(
cd sub1 &&
git fetch &&
git checkout -b "modifications" &&
echo "z" >file2 &&
echo "x" >file3 &&
git add file2 file3 &&
git commit -m "modified file2 and added file3" &&
git push origin modifications
) &&
git add sub1 &&
git commit -m "Modify sub1" &&
git checkout -b add_nested_sub modify_sub1 &&
git -C sub1 checkout -b "add_nested_sub" &&
git -C sub1 submodule add --branch no_submodule ../submodule_update_sub2 sub2 &&
git -C sub1 commit -a -m "add a nested submodule" &&
git add sub1 &&
git commit -a -m "update submodule, that updates a nested submodule" &&
git checkout -b modify_sub1_recursively &&
git -C sub1 checkout -b modify_sub1_recursively &&
git -C sub1/sub2 checkout -b modify_sub1_recursively &&
echo change >sub1/sub2/file3 &&
git -C sub1/sub2 add file3 &&
git -C sub1/sub2 commit -m "make a change in nested sub" &&
git -C sub1 add sub2 &&
git -C sub1 commit -m "update nested sub" &&
git add sub1 &&
git commit -m "update sub1, that updates nested sub" &&
git -C sub1 push origin modify_sub1_recursively &&
git -C sub1/sub2 push origin modify_sub1_recursively &&
git -C sub1 submodule deinit -f --all &&
git checkout -b replace_sub1_with_directory add_sub1 &&
submodules: add the lib-submodule-update.sh test library Add this test library to simplify covering all combinations of submodule update scenarios without having to add those to a test of each work tree manipulating command over and over again. The functions test_submodule_switch() and test_submodule_forced_switch() are intended to be called from a test script with a single argument. This argument is either a work tree manipulating command (including any command line options) or a function (when more than a single git command is needed to switch work trees from the current HEAD to another commit). This command (or function) is passed a target branch as argument. The two new functions check that each submodule transition is handled as expected, which currently means that submodule work trees are not affected until "git submodule update" is called. The "forced" variant is for commands using their '-f' or '--hard' option and expects them to overwrite local modifications as a result. Each of these two functions contains 14 tests_expect_* calls. Calling one of these test functions the first time creates a repository named "submodule_update_repo". At first it contains two files, then a single submodule is added in another commit followed by commits covering all relevant submodule modifications. This repository is newly cloned into the "submodule_update" for each test_expect_* to avoid interference between different parts of the test functions (some to-be-tested commands also manipulate refs along with the work tree, e.g. "git reset"). Follow-up commits will then call these two test functions for all work tree manipulating commands (with a combination of all their options relevant to what they do with the work tree) making sure they work as expected. Later this test library will be extended to cover merges resulting in conflicts too. Also it is intended to be easily extendable for the recursive update functionality, where even more combinations of submodule modifications have to be tested for. This version documents two bugs in current Git with expected failures: *) When a submodule is replaced with a tracked file of the same name the submodule work tree including any local modifications (and even the whole history if it uses a .git directory instead of a gitfile!) is silently removed. *) Forced work tree updates happily manipulate files in the directory of a submodule that has just been removed in the superproject (but is of course still present in the work tree due to the way submodules are currently handled). This becomes dangerous when files in the submodule directory are overwritten by files from the new superproject commit, as any modifications to the submodule files will be lost) and is expected to also destroy history in the - admittedly unlikely case - the new commit adds a file named ".git" to the submodule directory. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-07-01 23:24:14 +02:00
git submodule update &&
git -C sub1 checkout modifications &&
submodules: add the lib-submodule-update.sh test library Add this test library to simplify covering all combinations of submodule update scenarios without having to add those to a test of each work tree manipulating command over and over again. The functions test_submodule_switch() and test_submodule_forced_switch() are intended to be called from a test script with a single argument. This argument is either a work tree manipulating command (including any command line options) or a function (when more than a single git command is needed to switch work trees from the current HEAD to another commit). This command (or function) is passed a target branch as argument. The two new functions check that each submodule transition is handled as expected, which currently means that submodule work trees are not affected until "git submodule update" is called. The "forced" variant is for commands using their '-f' or '--hard' option and expects them to overwrite local modifications as a result. Each of these two functions contains 14 tests_expect_* calls. Calling one of these test functions the first time creates a repository named "submodule_update_repo". At first it contains two files, then a single submodule is added in another commit followed by commits covering all relevant submodule modifications. This repository is newly cloned into the "submodule_update" for each test_expect_* to avoid interference between different parts of the test functions (some to-be-tested commands also manipulate refs along with the work tree, e.g. "git reset"). Follow-up commits will then call these two test functions for all work tree manipulating commands (with a combination of all their options relevant to what they do with the work tree) making sure they work as expected. Later this test library will be extended to cover merges resulting in conflicts too. Also it is intended to be easily extendable for the recursive update functionality, where even more combinations of submodule modifications have to be tested for. This version documents two bugs in current Git with expected failures: *) When a submodule is replaced with a tracked file of the same name the submodule work tree including any local modifications (and even the whole history if it uses a .git directory instead of a gitfile!) is silently removed. *) Forced work tree updates happily manipulate files in the directory of a submodule that has just been removed in the superproject (but is of course still present in the work tree due to the way submodules are currently handled). This becomes dangerous when files in the submodule directory are overwritten by files from the new superproject commit, as any modifications to the submodule files will be lost) and is expected to also destroy history in the - admittedly unlikely case - the new commit adds a file named ".git" to the submodule directory. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-07-01 23:24:14 +02:00
git rm --cached sub1 &&
rm sub1/.git* &&
git config -f .gitmodules --remove-section "submodule.sub1" &&
git add .gitmodules sub1/* &&
git commit -m "Replace sub1 with directory" &&
submodules: add the lib-submodule-update.sh test library Add this test library to simplify covering all combinations of submodule update scenarios without having to add those to a test of each work tree manipulating command over and over again. The functions test_submodule_switch() and test_submodule_forced_switch() are intended to be called from a test script with a single argument. This argument is either a work tree manipulating command (including any command line options) or a function (when more than a single git command is needed to switch work trees from the current HEAD to another commit). This command (or function) is passed a target branch as argument. The two new functions check that each submodule transition is handled as expected, which currently means that submodule work trees are not affected until "git submodule update" is called. The "forced" variant is for commands using their '-f' or '--hard' option and expects them to overwrite local modifications as a result. Each of these two functions contains 14 tests_expect_* calls. Calling one of these test functions the first time creates a repository named "submodule_update_repo". At first it contains two files, then a single submodule is added in another commit followed by commits covering all relevant submodule modifications. This repository is newly cloned into the "submodule_update" for each test_expect_* to avoid interference between different parts of the test functions (some to-be-tested commands also manipulate refs along with the work tree, e.g. "git reset"). Follow-up commits will then call these two test functions for all work tree manipulating commands (with a combination of all their options relevant to what they do with the work tree) making sure they work as expected. Later this test library will be extended to cover merges resulting in conflicts too. Also it is intended to be easily extendable for the recursive update functionality, where even more combinations of submodule modifications have to be tested for. This version documents two bugs in current Git with expected failures: *) When a submodule is replaced with a tracked file of the same name the submodule work tree including any local modifications (and even the whole history if it uses a .git directory instead of a gitfile!) is silently removed. *) Forced work tree updates happily manipulate files in the directory of a submodule that has just been removed in the superproject (but is of course still present in the work tree due to the way submodules are currently handled). This becomes dangerous when files in the submodule directory are overwritten by files from the new superproject commit, as any modifications to the submodule files will be lost) and is expected to also destroy history in the - admittedly unlikely case - the new commit adds a file named ".git" to the submodule directory. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-07-01 23:24:14 +02:00
git checkout -b replace_directory_with_sub1 &&
git revert HEAD &&
git checkout -b replace_sub1_with_file add_sub1 &&
submodules: add the lib-submodule-update.sh test library Add this test library to simplify covering all combinations of submodule update scenarios without having to add those to a test of each work tree manipulating command over and over again. The functions test_submodule_switch() and test_submodule_forced_switch() are intended to be called from a test script with a single argument. This argument is either a work tree manipulating command (including any command line options) or a function (when more than a single git command is needed to switch work trees from the current HEAD to another commit). This command (or function) is passed a target branch as argument. The two new functions check that each submodule transition is handled as expected, which currently means that submodule work trees are not affected until "git submodule update" is called. The "forced" variant is for commands using their '-f' or '--hard' option and expects them to overwrite local modifications as a result. Each of these two functions contains 14 tests_expect_* calls. Calling one of these test functions the first time creates a repository named "submodule_update_repo". At first it contains two files, then a single submodule is added in another commit followed by commits covering all relevant submodule modifications. This repository is newly cloned into the "submodule_update" for each test_expect_* to avoid interference between different parts of the test functions (some to-be-tested commands also manipulate refs along with the work tree, e.g. "git reset"). Follow-up commits will then call these two test functions for all work tree manipulating commands (with a combination of all their options relevant to what they do with the work tree) making sure they work as expected. Later this test library will be extended to cover merges resulting in conflicts too. Also it is intended to be easily extendable for the recursive update functionality, where even more combinations of submodule modifications have to be tested for. This version documents two bugs in current Git with expected failures: *) When a submodule is replaced with a tracked file of the same name the submodule work tree including any local modifications (and even the whole history if it uses a .git directory instead of a gitfile!) is silently removed. *) Forced work tree updates happily manipulate files in the directory of a submodule that has just been removed in the superproject (but is of course still present in the work tree due to the way submodules are currently handled). This becomes dangerous when files in the submodule directory are overwritten by files from the new superproject commit, as any modifications to the submodule files will be lost) and is expected to also destroy history in the - admittedly unlikely case - the new commit adds a file named ".git" to the submodule directory. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-07-01 23:24:14 +02:00
git rm sub1 &&
echo "content" >sub1 &&
git add sub1 &&
git commit -m "Replace sub1 with file" &&
submodules: add the lib-submodule-update.sh test library Add this test library to simplify covering all combinations of submodule update scenarios without having to add those to a test of each work tree manipulating command over and over again. The functions test_submodule_switch() and test_submodule_forced_switch() are intended to be called from a test script with a single argument. This argument is either a work tree manipulating command (including any command line options) or a function (when more than a single git command is needed to switch work trees from the current HEAD to another commit). This command (or function) is passed a target branch as argument. The two new functions check that each submodule transition is handled as expected, which currently means that submodule work trees are not affected until "git submodule update" is called. The "forced" variant is for commands using their '-f' or '--hard' option and expects them to overwrite local modifications as a result. Each of these two functions contains 14 tests_expect_* calls. Calling one of these test functions the first time creates a repository named "submodule_update_repo". At first it contains two files, then a single submodule is added in another commit followed by commits covering all relevant submodule modifications. This repository is newly cloned into the "submodule_update" for each test_expect_* to avoid interference between different parts of the test functions (some to-be-tested commands also manipulate refs along with the work tree, e.g. "git reset"). Follow-up commits will then call these two test functions for all work tree manipulating commands (with a combination of all their options relevant to what they do with the work tree) making sure they work as expected. Later this test library will be extended to cover merges resulting in conflicts too. Also it is intended to be easily extendable for the recursive update functionality, where even more combinations of submodule modifications have to be tested for. This version documents two bugs in current Git with expected failures: *) When a submodule is replaced with a tracked file of the same name the submodule work tree including any local modifications (and even the whole history if it uses a .git directory instead of a gitfile!) is silently removed. *) Forced work tree updates happily manipulate files in the directory of a submodule that has just been removed in the superproject (but is of course still present in the work tree due to the way submodules are currently handled). This becomes dangerous when files in the submodule directory are overwritten by files from the new superproject commit, as any modifications to the submodule files will be lost) and is expected to also destroy history in the - admittedly unlikely case - the new commit adds a file named ".git" to the submodule directory. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-07-01 23:24:14 +02:00
git checkout -b replace_file_with_sub1 &&
git revert HEAD &&
git checkout -b invalid_sub1 add_sub1 &&
git update-index --cacheinfo 160000 $(test_oid numeric) sub1 &&
submodules: add the lib-submodule-update.sh test library Add this test library to simplify covering all combinations of submodule update scenarios without having to add those to a test of each work tree manipulating command over and over again. The functions test_submodule_switch() and test_submodule_forced_switch() are intended to be called from a test script with a single argument. This argument is either a work tree manipulating command (including any command line options) or a function (when more than a single git command is needed to switch work trees from the current HEAD to another commit). This command (or function) is passed a target branch as argument. The two new functions check that each submodule transition is handled as expected, which currently means that submodule work trees are not affected until "git submodule update" is called. The "forced" variant is for commands using their '-f' or '--hard' option and expects them to overwrite local modifications as a result. Each of these two functions contains 14 tests_expect_* calls. Calling one of these test functions the first time creates a repository named "submodule_update_repo". At first it contains two files, then a single submodule is added in another commit followed by commits covering all relevant submodule modifications. This repository is newly cloned into the "submodule_update" for each test_expect_* to avoid interference between different parts of the test functions (some to-be-tested commands also manipulate refs along with the work tree, e.g. "git reset"). Follow-up commits will then call these two test functions for all work tree manipulating commands (with a combination of all their options relevant to what they do with the work tree) making sure they work as expected. Later this test library will be extended to cover merges resulting in conflicts too. Also it is intended to be easily extendable for the recursive update functionality, where even more combinations of submodule modifications have to be tested for. This version documents two bugs in current Git with expected failures: *) When a submodule is replaced with a tracked file of the same name the submodule work tree including any local modifications (and even the whole history if it uses a .git directory instead of a gitfile!) is silently removed. *) Forced work tree updates happily manipulate files in the directory of a submodule that has just been removed in the superproject (but is of course still present in the work tree due to the way submodules are currently handled). This becomes dangerous when files in the submodule directory are overwritten by files from the new superproject commit, as any modifications to the submodule files will be lost) and is expected to also destroy history in the - admittedly unlikely case - the new commit adds a file named ".git" to the submodule directory. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-07-01 23:24:14 +02:00
git commit -m "Invalid sub1 commit" &&
git checkout -b valid_sub1 &&
git revert HEAD &&
git checkout "${GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME-master}"
submodules: add the lib-submodule-update.sh test library Add this test library to simplify covering all combinations of submodule update scenarios without having to add those to a test of each work tree manipulating command over and over again. The functions test_submodule_switch() and test_submodule_forced_switch() are intended to be called from a test script with a single argument. This argument is either a work tree manipulating command (including any command line options) or a function (when more than a single git command is needed to switch work trees from the current HEAD to another commit). This command (or function) is passed a target branch as argument. The two new functions check that each submodule transition is handled as expected, which currently means that submodule work trees are not affected until "git submodule update" is called. The "forced" variant is for commands using their '-f' or '--hard' option and expects them to overwrite local modifications as a result. Each of these two functions contains 14 tests_expect_* calls. Calling one of these test functions the first time creates a repository named "submodule_update_repo". At first it contains two files, then a single submodule is added in another commit followed by commits covering all relevant submodule modifications. This repository is newly cloned into the "submodule_update" for each test_expect_* to avoid interference between different parts of the test functions (some to-be-tested commands also manipulate refs along with the work tree, e.g. "git reset"). Follow-up commits will then call these two test functions for all work tree manipulating commands (with a combination of all their options relevant to what they do with the work tree) making sure they work as expected. Later this test library will be extended to cover merges resulting in conflicts too. Also it is intended to be easily extendable for the recursive update functionality, where even more combinations of submodule modifications have to be tested for. This version documents two bugs in current Git with expected failures: *) When a submodule is replaced with a tracked file of the same name the submodule work tree including any local modifications (and even the whole history if it uses a .git directory instead of a gitfile!) is silently removed. *) Forced work tree updates happily manipulate files in the directory of a submodule that has just been removed in the superproject (but is of course still present in the work tree due to the way submodules are currently handled). This becomes dangerous when files in the submodule directory are overwritten by files from the new superproject commit, as any modifications to the submodule files will be lost) and is expected to also destroy history in the - admittedly unlikely case - the new commit adds a file named ".git" to the submodule directory. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-07-01 23:24:14 +02:00
)
}
# Helper function to replace gitfile with .git directory
replace_gitfile_with_git_dir () {
(
cd "$1" &&
git_dir="$(git rev-parse --git-dir)" &&
rm -f .git &&
cp -R "$git_dir" .git &&
GIT_WORK_TREE=. git config --unset core.worktree
)
}
# Test that the .git directory in the submodule is unchanged (except for the
# core.worktree setting, which appears only in $GIT_DIR/modules/$1/config).
# Call this function before test_submodule_content as the latter might
# write the index file leading to false positive index differences.
#
# Note that this only supports submodules at the root level of the
# superproject, with the default name, i.e. same as its path.
test_git_directory_is_unchanged () {
(
cd ".git/modules/$1" &&
# does core.worktree point at the right place?
test "$(git config core.worktree)" = "../../../$1" &&
# remove it temporarily before comparing, as
# "$1/.git/config" lacks it...
git config --unset core.worktree
) &&
diff -r ".git/modules/$1" "$1/.git" &&
(
# ... and then restore.
cd ".git/modules/$1" &&
git config core.worktree "../../../$1"
)
}
test_git_directory_exists () {
test -e ".git/modules/$1" &&
if test -f sub1/.git
then
# does core.worktree point at the right place?
test "$(git -C .git/modules/$1 config core.worktree)" = "../../../$1"
fi
}
submodules: add the lib-submodule-update.sh test library Add this test library to simplify covering all combinations of submodule update scenarios without having to add those to a test of each work tree manipulating command over and over again. The functions test_submodule_switch() and test_submodule_forced_switch() are intended to be called from a test script with a single argument. This argument is either a work tree manipulating command (including any command line options) or a function (when more than a single git command is needed to switch work trees from the current HEAD to another commit). This command (or function) is passed a target branch as argument. The two new functions check that each submodule transition is handled as expected, which currently means that submodule work trees are not affected until "git submodule update" is called. The "forced" variant is for commands using their '-f' or '--hard' option and expects them to overwrite local modifications as a result. Each of these two functions contains 14 tests_expect_* calls. Calling one of these test functions the first time creates a repository named "submodule_update_repo". At first it contains two files, then a single submodule is added in another commit followed by commits covering all relevant submodule modifications. This repository is newly cloned into the "submodule_update" for each test_expect_* to avoid interference between different parts of the test functions (some to-be-tested commands also manipulate refs along with the work tree, e.g. "git reset"). Follow-up commits will then call these two test functions for all work tree manipulating commands (with a combination of all their options relevant to what they do with the work tree) making sure they work as expected. Later this test library will be extended to cover merges resulting in conflicts too. Also it is intended to be easily extendable for the recursive update functionality, where even more combinations of submodule modifications have to be tested for. This version documents two bugs in current Git with expected failures: *) When a submodule is replaced with a tracked file of the same name the submodule work tree including any local modifications (and even the whole history if it uses a .git directory instead of a gitfile!) is silently removed. *) Forced work tree updates happily manipulate files in the directory of a submodule that has just been removed in the superproject (but is of course still present in the work tree due to the way submodules are currently handled). This becomes dangerous when files in the submodule directory are overwritten by files from the new superproject commit, as any modifications to the submodule files will be lost) and is expected to also destroy history in the - admittedly unlikely case - the new commit adds a file named ".git" to the submodule directory. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-07-01 23:24:14 +02:00
# Helper function to be executed at the start of every test below, it sets up
# the submodule repo if it doesn't exist and configures the most problematic
# settings for diff.ignoreSubmodules.
prolog () {
(test -d submodule_update_repo || create_lib_submodule_repo) &&
test_config_global diff.ignoreSubmodules all &&
test_config diff.ignoreSubmodules all
}
# Helper function to bring work tree back into the state given by the
# commit. This includes trying to populate sub1 accordingly if it exists and
# should be updated to an existing commit.
reset_work_tree_to () {
rm -rf submodule_update &&
git clone submodule_update_repo submodule_update &&
(
cd submodule_update &&
rm -rf sub1 &&
git checkout -f "$1" &&
git status -u -s >actual &&
test_must_be_empty actual &&
hash=$(git rev-parse --revs-only HEAD:sub1) &&
if test -n "$hash" &&
test $(cd "../submodule_update_sub1" && git rev-parse --verify "$hash^{commit}")
submodules: add the lib-submodule-update.sh test library Add this test library to simplify covering all combinations of submodule update scenarios without having to add those to a test of each work tree manipulating command over and over again. The functions test_submodule_switch() and test_submodule_forced_switch() are intended to be called from a test script with a single argument. This argument is either a work tree manipulating command (including any command line options) or a function (when more than a single git command is needed to switch work trees from the current HEAD to another commit). This command (or function) is passed a target branch as argument. The two new functions check that each submodule transition is handled as expected, which currently means that submodule work trees are not affected until "git submodule update" is called. The "forced" variant is for commands using their '-f' or '--hard' option and expects them to overwrite local modifications as a result. Each of these two functions contains 14 tests_expect_* calls. Calling one of these test functions the first time creates a repository named "submodule_update_repo". At first it contains two files, then a single submodule is added in another commit followed by commits covering all relevant submodule modifications. This repository is newly cloned into the "submodule_update" for each test_expect_* to avoid interference between different parts of the test functions (some to-be-tested commands also manipulate refs along with the work tree, e.g. "git reset"). Follow-up commits will then call these two test functions for all work tree manipulating commands (with a combination of all their options relevant to what they do with the work tree) making sure they work as expected. Later this test library will be extended to cover merges resulting in conflicts too. Also it is intended to be easily extendable for the recursive update functionality, where even more combinations of submodule modifications have to be tested for. This version documents two bugs in current Git with expected failures: *) When a submodule is replaced with a tracked file of the same name the submodule work tree including any local modifications (and even the whole history if it uses a .git directory instead of a gitfile!) is silently removed. *) Forced work tree updates happily manipulate files in the directory of a submodule that has just been removed in the superproject (but is of course still present in the work tree due to the way submodules are currently handled). This becomes dangerous when files in the submodule directory are overwritten by files from the new superproject commit, as any modifications to the submodule files will be lost) and is expected to also destroy history in the - admittedly unlikely case - the new commit adds a file named ".git" to the submodule directory. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-07-01 23:24:14 +02:00
then
git submodule update --init --recursive "sub1"
fi
)
}
reset_work_tree_to_interested () {
reset_work_tree_to $1 &&
# make the submodule git dirs available
if ! test -d submodule_update/.git/modules/sub1
then
mkdir -p submodule_update/.git/modules &&
cp -r submodule_update_repo/.git/modules/sub1 submodule_update/.git/modules/sub1
GIT_WORK_TREE=. git -C submodule_update/.git/modules/sub1 config --unset core.worktree
fi &&
if ! test -d submodule_update/.git/modules/sub1/modules/sub2
then
mkdir -p submodule_update/.git/modules/sub1/modules &&
cp -r submodule_update_repo/.git/modules/sub1/modules/sub2 submodule_update/.git/modules/sub1/modules/sub2
# core.worktree is unset for sub2 as it is not checked out
fi &&
# indicate we are interested in the submodule:
git -C submodule_update config submodule.sub1.url "bogus" &&
# sub1 might not be checked out, so use the git dir
git -C submodule_update/.git/modules/sub1 config submodule.sub2.url "bogus"
}
submodules: add the lib-submodule-update.sh test library Add this test library to simplify covering all combinations of submodule update scenarios without having to add those to a test of each work tree manipulating command over and over again. The functions test_submodule_switch() and test_submodule_forced_switch() are intended to be called from a test script with a single argument. This argument is either a work tree manipulating command (including any command line options) or a function (when more than a single git command is needed to switch work trees from the current HEAD to another commit). This command (or function) is passed a target branch as argument. The two new functions check that each submodule transition is handled as expected, which currently means that submodule work trees are not affected until "git submodule update" is called. The "forced" variant is for commands using their '-f' or '--hard' option and expects them to overwrite local modifications as a result. Each of these two functions contains 14 tests_expect_* calls. Calling one of these test functions the first time creates a repository named "submodule_update_repo". At first it contains two files, then a single submodule is added in another commit followed by commits covering all relevant submodule modifications. This repository is newly cloned into the "submodule_update" for each test_expect_* to avoid interference between different parts of the test functions (some to-be-tested commands also manipulate refs along with the work tree, e.g. "git reset"). Follow-up commits will then call these two test functions for all work tree manipulating commands (with a combination of all their options relevant to what they do with the work tree) making sure they work as expected. Later this test library will be extended to cover merges resulting in conflicts too. Also it is intended to be easily extendable for the recursive update functionality, where even more combinations of submodule modifications have to be tested for. This version documents two bugs in current Git with expected failures: *) When a submodule is replaced with a tracked file of the same name the submodule work tree including any local modifications (and even the whole history if it uses a .git directory instead of a gitfile!) is silently removed. *) Forced work tree updates happily manipulate files in the directory of a submodule that has just been removed in the superproject (but is of course still present in the work tree due to the way submodules are currently handled). This becomes dangerous when files in the submodule directory are overwritten by files from the new superproject commit, as any modifications to the submodule files will be lost) and is expected to also destroy history in the - admittedly unlikely case - the new commit adds a file named ".git" to the submodule directory. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-07-01 23:24:14 +02:00
# Test that the superproject contains the content according to commit "$1"
# (the work tree must match the index for everything but submodules but the
# index must exactly match the given commit including any submodule SHA-1s).
test_superproject_content () {
git diff-index --cached "$1" >actual &&
test_must_be_empty actual &&
git diff-files --ignore-submodules >actual &&
test_must_be_empty actual
}
# Test that the given submodule at path "$1" contains the content according
# to the submodule commit recorded in the superproject's commit "$2"
test_submodule_content () {
if test x"$1" = "x-C"
then
cd "$2"
shift; shift;
fi
submodules: add the lib-submodule-update.sh test library Add this test library to simplify covering all combinations of submodule update scenarios without having to add those to a test of each work tree manipulating command over and over again. The functions test_submodule_switch() and test_submodule_forced_switch() are intended to be called from a test script with a single argument. This argument is either a work tree manipulating command (including any command line options) or a function (when more than a single git command is needed to switch work trees from the current HEAD to another commit). This command (or function) is passed a target branch as argument. The two new functions check that each submodule transition is handled as expected, which currently means that submodule work trees are not affected until "git submodule update" is called. The "forced" variant is for commands using their '-f' or '--hard' option and expects them to overwrite local modifications as a result. Each of these two functions contains 14 tests_expect_* calls. Calling one of these test functions the first time creates a repository named "submodule_update_repo". At first it contains two files, then a single submodule is added in another commit followed by commits covering all relevant submodule modifications. This repository is newly cloned into the "submodule_update" for each test_expect_* to avoid interference between different parts of the test functions (some to-be-tested commands also manipulate refs along with the work tree, e.g. "git reset"). Follow-up commits will then call these two test functions for all work tree manipulating commands (with a combination of all their options relevant to what they do with the work tree) making sure they work as expected. Later this test library will be extended to cover merges resulting in conflicts too. Also it is intended to be easily extendable for the recursive update functionality, where even more combinations of submodule modifications have to be tested for. This version documents two bugs in current Git with expected failures: *) When a submodule is replaced with a tracked file of the same name the submodule work tree including any local modifications (and even the whole history if it uses a .git directory instead of a gitfile!) is silently removed. *) Forced work tree updates happily manipulate files in the directory of a submodule that has just been removed in the superproject (but is of course still present in the work tree due to the way submodules are currently handled). This becomes dangerous when files in the submodule directory are overwritten by files from the new superproject commit, as any modifications to the submodule files will be lost) and is expected to also destroy history in the - admittedly unlikely case - the new commit adds a file named ".git" to the submodule directory. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-07-01 23:24:14 +02:00
if test $# != 2
then
echo "test_submodule_content needs two arguments"
return 1
fi &&
submodule="$1" &&
commit="$2" &&
test -d "$submodule"/ &&
if ! test -f "$submodule"/.git && ! test -d "$submodule"/.git
then
echo "Submodule $submodule is not populated"
return 1
fi &&
sha1=$(git rev-parse --verify "$commit:$submodule") &&
if test -z "$sha1"
then
echo "Couldn't retrieve SHA-1 of $submodule for $commit"
return 1
fi &&
(
cd "$submodule" &&
git status -u -s >actual &&
test_must_be_empty actual &&
git diff "$sha1" >actual &&
test_must_be_empty actual
)
}
# Test that the following transitions are correctly handled:
# - Updated submodule
# - New submodule
# - Removed submodule
# - Directory containing tracked files replaced by submodule
# - Submodule replaced by tracked files in directory
# - Submodule replaced by tracked file with the same name
# - Tracked file replaced by submodule
submodules: add the lib-submodule-update.sh test library Add this test library to simplify covering all combinations of submodule update scenarios without having to add those to a test of each work tree manipulating command over and over again. The functions test_submodule_switch() and test_submodule_forced_switch() are intended to be called from a test script with a single argument. This argument is either a work tree manipulating command (including any command line options) or a function (when more than a single git command is needed to switch work trees from the current HEAD to another commit). This command (or function) is passed a target branch as argument. The two new functions check that each submodule transition is handled as expected, which currently means that submodule work trees are not affected until "git submodule update" is called. The "forced" variant is for commands using their '-f' or '--hard' option and expects them to overwrite local modifications as a result. Each of these two functions contains 14 tests_expect_* calls. Calling one of these test functions the first time creates a repository named "submodule_update_repo". At first it contains two files, then a single submodule is added in another commit followed by commits covering all relevant submodule modifications. This repository is newly cloned into the "submodule_update" for each test_expect_* to avoid interference between different parts of the test functions (some to-be-tested commands also manipulate refs along with the work tree, e.g. "git reset"). Follow-up commits will then call these two test functions for all work tree manipulating commands (with a combination of all their options relevant to what they do with the work tree) making sure they work as expected. Later this test library will be extended to cover merges resulting in conflicts too. Also it is intended to be easily extendable for the recursive update functionality, where even more combinations of submodule modifications have to be tested for. This version documents two bugs in current Git with expected failures: *) When a submodule is replaced with a tracked file of the same name the submodule work tree including any local modifications (and even the whole history if it uses a .git directory instead of a gitfile!) is silently removed. *) Forced work tree updates happily manipulate files in the directory of a submodule that has just been removed in the superproject (but is of course still present in the work tree due to the way submodules are currently handled). This becomes dangerous when files in the submodule directory are overwritten by files from the new superproject commit, as any modifications to the submodule files will be lost) and is expected to also destroy history in the - admittedly unlikely case - the new commit adds a file named ".git" to the submodule directory. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-07-01 23:24:14 +02:00
#
# The default is that submodule contents aren't changed until "git submodule
# update" is run. And even then that command doesn't delete the work tree of
# a removed submodule.
#
lib-submodule-update: pass 'test_must_fail' as an argument When we run a test helper function in test_submodule_switch_common(), we sometimes specify a whole helper function as the $command. When we do this, in some test cases, we just mark the whole function with `test_must_fail`. However, it's possible that the helper function might fail earlier or later than expected due to an introduced bug. If this happens, then the test case will still report as passing but it should really be marked as failing since it didn't actually display the intended behaviour. Instead of invoking `test_must_fail $command`, pass the string "test_must_fail" as the second argument in case where the git command is expected to fail. When $command is a helper function, the parent function calling test_submodule_switch_common() is test_submodule_switch_func(). For all test_submodule_switch_func() invocations, increase the granularity of the argument test helper function by prefixing the git invocation which is meant to fail with the second argument like this: $2 git checkout "$1" In the other cases, test_submodule_switch() and test_submodule_forced_switch(), instead of passing in the git command directly, wrap it using the git_test_func() and pass the git arguments using the global variable $gitcmd. Unfortunately, since closures aren't a thing in shell scripts, the global variable is necessary. Another unfortunate result is that the "git_test_func" will used as the test case name when $command is printed but it's worth it for the cleaner code. Finally, as an added bonus, `test_must_fail` will now only run on git commands. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-24 10:50:18 +02:00
# The first argument of the callback function will be the name of the submodule.
#
submodules: add the lib-submodule-update.sh test library Add this test library to simplify covering all combinations of submodule update scenarios without having to add those to a test of each work tree manipulating command over and over again. The functions test_submodule_switch() and test_submodule_forced_switch() are intended to be called from a test script with a single argument. This argument is either a work tree manipulating command (including any command line options) or a function (when more than a single git command is needed to switch work trees from the current HEAD to another commit). This command (or function) is passed a target branch as argument. The two new functions check that each submodule transition is handled as expected, which currently means that submodule work trees are not affected until "git submodule update" is called. The "forced" variant is for commands using their '-f' or '--hard' option and expects them to overwrite local modifications as a result. Each of these two functions contains 14 tests_expect_* calls. Calling one of these test functions the first time creates a repository named "submodule_update_repo". At first it contains two files, then a single submodule is added in another commit followed by commits covering all relevant submodule modifications. This repository is newly cloned into the "submodule_update" for each test_expect_* to avoid interference between different parts of the test functions (some to-be-tested commands also manipulate refs along with the work tree, e.g. "git reset"). Follow-up commits will then call these two test functions for all work tree manipulating commands (with a combination of all their options relevant to what they do with the work tree) making sure they work as expected. Later this test library will be extended to cover merges resulting in conflicts too. Also it is intended to be easily extendable for the recursive update functionality, where even more combinations of submodule modifications have to be tested for. This version documents two bugs in current Git with expected failures: *) When a submodule is replaced with a tracked file of the same name the submodule work tree including any local modifications (and even the whole history if it uses a .git directory instead of a gitfile!) is silently removed. *) Forced work tree updates happily manipulate files in the directory of a submodule that has just been removed in the superproject (but is of course still present in the work tree due to the way submodules are currently handled). This becomes dangerous when files in the submodule directory are overwritten by files from the new superproject commit, as any modifications to the submodule files will be lost) and is expected to also destroy history in the - admittedly unlikely case - the new commit adds a file named ".git" to the submodule directory. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-07-01 23:24:14 +02:00
# Removing a submodule containing a .git directory must fail even when forced
lib-submodule-update: pass 'test_must_fail' as an argument When we run a test helper function in test_submodule_switch_common(), we sometimes specify a whole helper function as the $command. When we do this, in some test cases, we just mark the whole function with `test_must_fail`. However, it's possible that the helper function might fail earlier or later than expected due to an introduced bug. If this happens, then the test case will still report as passing but it should really be marked as failing since it didn't actually display the intended behaviour. Instead of invoking `test_must_fail $command`, pass the string "test_must_fail" as the second argument in case where the git command is expected to fail. When $command is a helper function, the parent function calling test_submodule_switch_common() is test_submodule_switch_func(). For all test_submodule_switch_func() invocations, increase the granularity of the argument test helper function by prefixing the git invocation which is meant to fail with the second argument like this: $2 git checkout "$1" In the other cases, test_submodule_switch() and test_submodule_forced_switch(), instead of passing in the git command directly, wrap it using the git_test_func() and pass the git arguments using the global variable $gitcmd. Unfortunately, since closures aren't a thing in shell scripts, the global variable is necessary. Another unfortunate result is that the "git_test_func" will used as the test case name when $command is printed but it's worth it for the cleaner code. Finally, as an added bonus, `test_must_fail` will now only run on git commands. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-24 10:50:18 +02:00
# to protect the history! If we are testing this case, the second argument of
# the callback function will be 'test_must_fail', else it will be the empty
# string.
submodules: add the lib-submodule-update.sh test library Add this test library to simplify covering all combinations of submodule update scenarios without having to add those to a test of each work tree manipulating command over and over again. The functions test_submodule_switch() and test_submodule_forced_switch() are intended to be called from a test script with a single argument. This argument is either a work tree manipulating command (including any command line options) or a function (when more than a single git command is needed to switch work trees from the current HEAD to another commit). This command (or function) is passed a target branch as argument. The two new functions check that each submodule transition is handled as expected, which currently means that submodule work trees are not affected until "git submodule update" is called. The "forced" variant is for commands using their '-f' or '--hard' option and expects them to overwrite local modifications as a result. Each of these two functions contains 14 tests_expect_* calls. Calling one of these test functions the first time creates a repository named "submodule_update_repo". At first it contains two files, then a single submodule is added in another commit followed by commits covering all relevant submodule modifications. This repository is newly cloned into the "submodule_update" for each test_expect_* to avoid interference between different parts of the test functions (some to-be-tested commands also manipulate refs along with the work tree, e.g. "git reset"). Follow-up commits will then call these two test functions for all work tree manipulating commands (with a combination of all their options relevant to what they do with the work tree) making sure they work as expected. Later this test library will be extended to cover merges resulting in conflicts too. Also it is intended to be easily extendable for the recursive update functionality, where even more combinations of submodule modifications have to be tested for. This version documents two bugs in current Git with expected failures: *) When a submodule is replaced with a tracked file of the same name the submodule work tree including any local modifications (and even the whole history if it uses a .git directory instead of a gitfile!) is silently removed. *) Forced work tree updates happily manipulate files in the directory of a submodule that has just been removed in the superproject (but is of course still present in the work tree due to the way submodules are currently handled). This becomes dangerous when files in the submodule directory are overwritten by files from the new superproject commit, as any modifications to the submodule files will be lost) and is expected to also destroy history in the - admittedly unlikely case - the new commit adds a file named ".git" to the submodule directory. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-07-01 23:24:14 +02:00
#
# Internal function; use test_submodule_switch_func(), test_submodule_switch(),
# or test_submodule_forced_switch() instead.
test_submodule_switch_common () {
submodules: add the lib-submodule-update.sh test library Add this test library to simplify covering all combinations of submodule update scenarios without having to add those to a test of each work tree manipulating command over and over again. The functions test_submodule_switch() and test_submodule_forced_switch() are intended to be called from a test script with a single argument. This argument is either a work tree manipulating command (including any command line options) or a function (when more than a single git command is needed to switch work trees from the current HEAD to another commit). This command (or function) is passed a target branch as argument. The two new functions check that each submodule transition is handled as expected, which currently means that submodule work trees are not affected until "git submodule update" is called. The "forced" variant is for commands using their '-f' or '--hard' option and expects them to overwrite local modifications as a result. Each of these two functions contains 14 tests_expect_* calls. Calling one of these test functions the first time creates a repository named "submodule_update_repo". At first it contains two files, then a single submodule is added in another commit followed by commits covering all relevant submodule modifications. This repository is newly cloned into the "submodule_update" for each test_expect_* to avoid interference between different parts of the test functions (some to-be-tested commands also manipulate refs along with the work tree, e.g. "git reset"). Follow-up commits will then call these two test functions for all work tree manipulating commands (with a combination of all their options relevant to what they do with the work tree) making sure they work as expected. Later this test library will be extended to cover merges resulting in conflicts too. Also it is intended to be easily extendable for the recursive update functionality, where even more combinations of submodule modifications have to be tested for. This version documents two bugs in current Git with expected failures: *) When a submodule is replaced with a tracked file of the same name the submodule work tree including any local modifications (and even the whole history if it uses a .git directory instead of a gitfile!) is silently removed. *) Forced work tree updates happily manipulate files in the directory of a submodule that has just been removed in the superproject (but is of course still present in the work tree due to the way submodules are currently handled). This becomes dangerous when files in the submodule directory are overwritten by files from the new superproject commit, as any modifications to the submodule files will be lost) and is expected to also destroy history in the - admittedly unlikely case - the new commit adds a file named ".git" to the submodule directory. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-07-01 23:24:14 +02:00
command="$1"
######################### Appearing submodule #########################
# Switching to a commit letting a submodule appear creates empty dir ...
stash: remove unnecessary process forking When stash was converted from shell to a builtin, it merely transliterated the forking of various git commands from shell to a C program that would fork the same commands. Some of those were converted over to actual library calls, but much of the pipeline-of-commands design still remains. Fix some of this by replacing the portion corresponding to git diff-index --cached --name-only --diff-filter=A $CTREE >"$a" git read-tree --reset $CTREE git update-index --add --stdin <"$a" rm -f "$a" into a library function that does the same thing. (The read-tree --reset was already partially converted over to a library call, but as an independent piece.) Note here that this came after a merge operation was performed. The merge machinery always stages anything that cleanly merges, and the above code only runs if there are no conflicts. Its purpose is to make it so that when there are no conflicts, all the changes from the stash are unstaged. However, that causes brand new files from the stash to become untracked, so the code above first saves those files off and then re-adds them afterwards. We replace the whole series of commands with a simple function that will unstage files that are not newly added. This doesn't fix any bugs in the usage of these commands, it simply matches the existing behavior but makes it into a single atomic operation that we can then operate on as a whole. A subsequent commit will take advantage of this to fix issues with these commands in sparse-checkouts. This conversion incidentally fixes t3906.1, because the separate update-index process would die with the following error messages: error: uninitialized_sub: is a directory - add files inside instead fatal: Unable to process path uninitialized_sub The unstaging of the directory as a submodule meant it was no longer tracked, and thus as an uninitialized directory it could not be added back using `git update-index --add`, thus resulting in this error and early abort. Most of the submodule tests in 3906 continue to fail after this change, this change was just enough to push the first of those tests to success. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-12-01 23:25:17 +01:00
test_expect_success "$command: added submodule creates empty directory" '
submodules: add the lib-submodule-update.sh test library Add this test library to simplify covering all combinations of submodule update scenarios without having to add those to a test of each work tree manipulating command over and over again. The functions test_submodule_switch() and test_submodule_forced_switch() are intended to be called from a test script with a single argument. This argument is either a work tree manipulating command (including any command line options) or a function (when more than a single git command is needed to switch work trees from the current HEAD to another commit). This command (or function) is passed a target branch as argument. The two new functions check that each submodule transition is handled as expected, which currently means that submodule work trees are not affected until "git submodule update" is called. The "forced" variant is for commands using their '-f' or '--hard' option and expects them to overwrite local modifications as a result. Each of these two functions contains 14 tests_expect_* calls. Calling one of these test functions the first time creates a repository named "submodule_update_repo". At first it contains two files, then a single submodule is added in another commit followed by commits covering all relevant submodule modifications. This repository is newly cloned into the "submodule_update" for each test_expect_* to avoid interference between different parts of the test functions (some to-be-tested commands also manipulate refs along with the work tree, e.g. "git reset"). Follow-up commits will then call these two test functions for all work tree manipulating commands (with a combination of all their options relevant to what they do with the work tree) making sure they work as expected. Later this test library will be extended to cover merges resulting in conflicts too. Also it is intended to be easily extendable for the recursive update functionality, where even more combinations of submodule modifications have to be tested for. This version documents two bugs in current Git with expected failures: *) When a submodule is replaced with a tracked file of the same name the submodule work tree including any local modifications (and even the whole history if it uses a .git directory instead of a gitfile!) is silently removed. *) Forced work tree updates happily manipulate files in the directory of a submodule that has just been removed in the superproject (but is of course still present in the work tree due to the way submodules are currently handled). This becomes dangerous when files in the submodule directory are overwritten by files from the new superproject commit, as any modifications to the submodule files will be lost) and is expected to also destroy history in the - admittedly unlikely case - the new commit adds a file named ".git" to the submodule directory. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-07-01 23:24:14 +02:00
prolog &&
reset_work_tree_to no_submodule &&
(
cd submodule_update &&
git branch -t add_sub1 origin/add_sub1 &&
$command add_sub1 &&
test_superproject_content origin/add_sub1 &&
test_dir_is_empty sub1 &&
git submodule update --init --recursive &&
test_submodule_content sub1 origin/add_sub1
)
'
# ... and doesn't care if it already exists.
stash: remove unnecessary process forking When stash was converted from shell to a builtin, it merely transliterated the forking of various git commands from shell to a C program that would fork the same commands. Some of those were converted over to actual library calls, but much of the pipeline-of-commands design still remains. Fix some of this by replacing the portion corresponding to git diff-index --cached --name-only --diff-filter=A $CTREE >"$a" git read-tree --reset $CTREE git update-index --add --stdin <"$a" rm -f "$a" into a library function that does the same thing. (The read-tree --reset was already partially converted over to a library call, but as an independent piece.) Note here that this came after a merge operation was performed. The merge machinery always stages anything that cleanly merges, and the above code only runs if there are no conflicts. Its purpose is to make it so that when there are no conflicts, all the changes from the stash are unstaged. However, that causes brand new files from the stash to become untracked, so the code above first saves those files off and then re-adds them afterwards. We replace the whole series of commands with a simple function that will unstage files that are not newly added. This doesn't fix any bugs in the usage of these commands, it simply matches the existing behavior but makes it into a single atomic operation that we can then operate on as a whole. A subsequent commit will take advantage of this to fix issues with these commands in sparse-checkouts. This conversion incidentally fixes t3906.1, because the separate update-index process would die with the following error messages: error: uninitialized_sub: is a directory - add files inside instead fatal: Unable to process path uninitialized_sub The unstaging of the directory as a submodule meant it was no longer tracked, and thus as an uninitialized directory it could not be added back using `git update-index --add`, thus resulting in this error and early abort. Most of the submodule tests in 3906 continue to fail after this change, this change was just enough to push the first of those tests to success. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-12-01 23:25:17 +01:00
if test "$KNOWN_FAILURE_STASH_DOES_IGNORE_SUBMODULE_CHANGES" = 1
then
# Restoring stash fails to restore submodule index entry
RESULT="failure"
else
RESULT="success"
fi
test_expect_$RESULT "$command: added submodule leaves existing empty directory alone" '
submodules: add the lib-submodule-update.sh test library Add this test library to simplify covering all combinations of submodule update scenarios without having to add those to a test of each work tree manipulating command over and over again. The functions test_submodule_switch() and test_submodule_forced_switch() are intended to be called from a test script with a single argument. This argument is either a work tree manipulating command (including any command line options) or a function (when more than a single git command is needed to switch work trees from the current HEAD to another commit). This command (or function) is passed a target branch as argument. The two new functions check that each submodule transition is handled as expected, which currently means that submodule work trees are not affected until "git submodule update" is called. The "forced" variant is for commands using their '-f' or '--hard' option and expects them to overwrite local modifications as a result. Each of these two functions contains 14 tests_expect_* calls. Calling one of these test functions the first time creates a repository named "submodule_update_repo". At first it contains two files, then a single submodule is added in another commit followed by commits covering all relevant submodule modifications. This repository is newly cloned into the "submodule_update" for each test_expect_* to avoid interference between different parts of the test functions (some to-be-tested commands also manipulate refs along with the work tree, e.g. "git reset"). Follow-up commits will then call these two test functions for all work tree manipulating commands (with a combination of all their options relevant to what they do with the work tree) making sure they work as expected. Later this test library will be extended to cover merges resulting in conflicts too. Also it is intended to be easily extendable for the recursive update functionality, where even more combinations of submodule modifications have to be tested for. This version documents two bugs in current Git with expected failures: *) When a submodule is replaced with a tracked file of the same name the submodule work tree including any local modifications (and even the whole history if it uses a .git directory instead of a gitfile!) is silently removed. *) Forced work tree updates happily manipulate files in the directory of a submodule that has just been removed in the superproject (but is of course still present in the work tree due to the way submodules are currently handled). This becomes dangerous when files in the submodule directory are overwritten by files from the new superproject commit, as any modifications to the submodule files will be lost) and is expected to also destroy history in the - admittedly unlikely case - the new commit adds a file named ".git" to the submodule directory. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-07-01 23:24:14 +02:00
prolog &&
reset_work_tree_to no_submodule &&
(
cd submodule_update &&
mkdir sub1 &&
git branch -t add_sub1 origin/add_sub1 &&
$command add_sub1 &&
test_superproject_content origin/add_sub1 &&
test_dir_is_empty sub1 &&
git submodule update --init --recursive &&
test_submodule_content sub1 origin/add_sub1
)
'
# Replacing a tracked file with a submodule produces an empty
# directory ...
test_expect_$RESULT "$command: replace tracked file with submodule creates empty directory" '
submodules: add the lib-submodule-update.sh test library Add this test library to simplify covering all combinations of submodule update scenarios without having to add those to a test of each work tree manipulating command over and over again. The functions test_submodule_switch() and test_submodule_forced_switch() are intended to be called from a test script with a single argument. This argument is either a work tree manipulating command (including any command line options) or a function (when more than a single git command is needed to switch work trees from the current HEAD to another commit). This command (or function) is passed a target branch as argument. The two new functions check that each submodule transition is handled as expected, which currently means that submodule work trees are not affected until "git submodule update" is called. The "forced" variant is for commands using their '-f' or '--hard' option and expects them to overwrite local modifications as a result. Each of these two functions contains 14 tests_expect_* calls. Calling one of these test functions the first time creates a repository named "submodule_update_repo". At first it contains two files, then a single submodule is added in another commit followed by commits covering all relevant submodule modifications. This repository is newly cloned into the "submodule_update" for each test_expect_* to avoid interference between different parts of the test functions (some to-be-tested commands also manipulate refs along with the work tree, e.g. "git reset"). Follow-up commits will then call these two test functions for all work tree manipulating commands (with a combination of all their options relevant to what they do with the work tree) making sure they work as expected. Later this test library will be extended to cover merges resulting in conflicts too. Also it is intended to be easily extendable for the recursive update functionality, where even more combinations of submodule modifications have to be tested for. This version documents two bugs in current Git with expected failures: *) When a submodule is replaced with a tracked file of the same name the submodule work tree including any local modifications (and even the whole history if it uses a .git directory instead of a gitfile!) is silently removed. *) Forced work tree updates happily manipulate files in the directory of a submodule that has just been removed in the superproject (but is of course still present in the work tree due to the way submodules are currently handled). This becomes dangerous when files in the submodule directory are overwritten by files from the new superproject commit, as any modifications to the submodule files will be lost) and is expected to also destroy history in the - admittedly unlikely case - the new commit adds a file named ".git" to the submodule directory. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-07-01 23:24:14 +02:00
prolog &&
reset_work_tree_to replace_sub1_with_file &&
(
cd submodule_update &&
git branch -t replace_file_with_sub1 origin/replace_file_with_sub1 &&
$command replace_file_with_sub1 &&
test_superproject_content origin/replace_file_with_sub1 &&
test_dir_is_empty sub1 &&
git submodule update --init --recursive &&
test_submodule_content sub1 origin/replace_file_with_sub1
)
'
# ... as does removing a directory with tracked files with a
# submodule.
if test "$KNOWN_FAILURE_NOFF_MERGE_DOESNT_CREATE_EMPTY_SUBMODULE_DIR" = 1
then
# Non fast-forward merges fail with "Directory sub1 doesn't
# exist. sub1" because the empty submodule directory is not
# created
RESULT="failure"
else
RESULT="success"
fi
test_expect_$RESULT "$command: replace directory with submodule" '
submodules: add the lib-submodule-update.sh test library Add this test library to simplify covering all combinations of submodule update scenarios without having to add those to a test of each work tree manipulating command over and over again. The functions test_submodule_switch() and test_submodule_forced_switch() are intended to be called from a test script with a single argument. This argument is either a work tree manipulating command (including any command line options) or a function (when more than a single git command is needed to switch work trees from the current HEAD to another commit). This command (or function) is passed a target branch as argument. The two new functions check that each submodule transition is handled as expected, which currently means that submodule work trees are not affected until "git submodule update" is called. The "forced" variant is for commands using their '-f' or '--hard' option and expects them to overwrite local modifications as a result. Each of these two functions contains 14 tests_expect_* calls. Calling one of these test functions the first time creates a repository named "submodule_update_repo". At first it contains two files, then a single submodule is added in another commit followed by commits covering all relevant submodule modifications. This repository is newly cloned into the "submodule_update" for each test_expect_* to avoid interference between different parts of the test functions (some to-be-tested commands also manipulate refs along with the work tree, e.g. "git reset"). Follow-up commits will then call these two test functions for all work tree manipulating commands (with a combination of all their options relevant to what they do with the work tree) making sure they work as expected. Later this test library will be extended to cover merges resulting in conflicts too. Also it is intended to be easily extendable for the recursive update functionality, where even more combinations of submodule modifications have to be tested for. This version documents two bugs in current Git with expected failures: *) When a submodule is replaced with a tracked file of the same name the submodule work tree including any local modifications (and even the whole history if it uses a .git directory instead of a gitfile!) is silently removed. *) Forced work tree updates happily manipulate files in the directory of a submodule that has just been removed in the superproject (but is of course still present in the work tree due to the way submodules are currently handled). This becomes dangerous when files in the submodule directory are overwritten by files from the new superproject commit, as any modifications to the submodule files will be lost) and is expected to also destroy history in the - admittedly unlikely case - the new commit adds a file named ".git" to the submodule directory. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-07-01 23:24:14 +02:00
prolog &&
reset_work_tree_to replace_sub1_with_directory &&
(
cd submodule_update &&
git branch -t replace_directory_with_sub1 origin/replace_directory_with_sub1 &&
$command replace_directory_with_sub1 &&
test_superproject_content origin/replace_directory_with_sub1 &&
test_dir_is_empty sub1 &&
git submodule update --init --recursive &&
test_submodule_content sub1 origin/replace_directory_with_sub1
)
'
######################## Disappearing submodule #######################
# Removing a submodule doesn't remove its work tree ...
if test "$KNOWN_FAILURE_STASH_DOES_IGNORE_SUBMODULE_CHANGES" = 1
then
RESULT="failure"
else
RESULT="success"
fi
test_expect_$RESULT "$command: removed submodule leaves submodule directory and its contents in place" '
submodules: add the lib-submodule-update.sh test library Add this test library to simplify covering all combinations of submodule update scenarios without having to add those to a test of each work tree manipulating command over and over again. The functions test_submodule_switch() and test_submodule_forced_switch() are intended to be called from a test script with a single argument. This argument is either a work tree manipulating command (including any command line options) or a function (when more than a single git command is needed to switch work trees from the current HEAD to another commit). This command (or function) is passed a target branch as argument. The two new functions check that each submodule transition is handled as expected, which currently means that submodule work trees are not affected until "git submodule update" is called. The "forced" variant is for commands using their '-f' or '--hard' option and expects them to overwrite local modifications as a result. Each of these two functions contains 14 tests_expect_* calls. Calling one of these test functions the first time creates a repository named "submodule_update_repo". At first it contains two files, then a single submodule is added in another commit followed by commits covering all relevant submodule modifications. This repository is newly cloned into the "submodule_update" for each test_expect_* to avoid interference between different parts of the test functions (some to-be-tested commands also manipulate refs along with the work tree, e.g. "git reset"). Follow-up commits will then call these two test functions for all work tree manipulating commands (with a combination of all their options relevant to what they do with the work tree) making sure they work as expected. Later this test library will be extended to cover merges resulting in conflicts too. Also it is intended to be easily extendable for the recursive update functionality, where even more combinations of submodule modifications have to be tested for. This version documents two bugs in current Git with expected failures: *) When a submodule is replaced with a tracked file of the same name the submodule work tree including any local modifications (and even the whole history if it uses a .git directory instead of a gitfile!) is silently removed. *) Forced work tree updates happily manipulate files in the directory of a submodule that has just been removed in the superproject (but is of course still present in the work tree due to the way submodules are currently handled). This becomes dangerous when files in the submodule directory are overwritten by files from the new superproject commit, as any modifications to the submodule files will be lost) and is expected to also destroy history in the - admittedly unlikely case - the new commit adds a file named ".git" to the submodule directory. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-07-01 23:24:14 +02:00
prolog &&
reset_work_tree_to add_sub1 &&
(
cd submodule_update &&
git branch -t remove_sub1 origin/remove_sub1 &&
$command remove_sub1 &&
test_superproject_content origin/remove_sub1 &&
test_submodule_content sub1 origin/add_sub1
)
'
# ... especially when it contains a .git directory.
test_expect_$RESULT "$command: removed submodule leaves submodule containing a .git directory alone" '
submodules: add the lib-submodule-update.sh test library Add this test library to simplify covering all combinations of submodule update scenarios without having to add those to a test of each work tree manipulating command over and over again. The functions test_submodule_switch() and test_submodule_forced_switch() are intended to be called from a test script with a single argument. This argument is either a work tree manipulating command (including any command line options) or a function (when more than a single git command is needed to switch work trees from the current HEAD to another commit). This command (or function) is passed a target branch as argument. The two new functions check that each submodule transition is handled as expected, which currently means that submodule work trees are not affected until "git submodule update" is called. The "forced" variant is for commands using their '-f' or '--hard' option and expects them to overwrite local modifications as a result. Each of these two functions contains 14 tests_expect_* calls. Calling one of these test functions the first time creates a repository named "submodule_update_repo". At first it contains two files, then a single submodule is added in another commit followed by commits covering all relevant submodule modifications. This repository is newly cloned into the "submodule_update" for each test_expect_* to avoid interference between different parts of the test functions (some to-be-tested commands also manipulate refs along with the work tree, e.g. "git reset"). Follow-up commits will then call these two test functions for all work tree manipulating commands (with a combination of all their options relevant to what they do with the work tree) making sure they work as expected. Later this test library will be extended to cover merges resulting in conflicts too. Also it is intended to be easily extendable for the recursive update functionality, where even more combinations of submodule modifications have to be tested for. This version documents two bugs in current Git with expected failures: *) When a submodule is replaced with a tracked file of the same name the submodule work tree including any local modifications (and even the whole history if it uses a .git directory instead of a gitfile!) is silently removed. *) Forced work tree updates happily manipulate files in the directory of a submodule that has just been removed in the superproject (but is of course still present in the work tree due to the way submodules are currently handled). This becomes dangerous when files in the submodule directory are overwritten by files from the new superproject commit, as any modifications to the submodule files will be lost) and is expected to also destroy history in the - admittedly unlikely case - the new commit adds a file named ".git" to the submodule directory. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-07-01 23:24:14 +02:00
prolog &&
reset_work_tree_to add_sub1 &&
(
cd submodule_update &&
git branch -t remove_sub1 origin/remove_sub1 &&
replace_gitfile_with_git_dir sub1 &&
$command remove_sub1 &&
test_superproject_content origin/remove_sub1 &&
test_git_directory_is_unchanged sub1 &&
test_submodule_content sub1 origin/add_sub1
)
'
# Replacing a submodule with files in a directory must fail as the
# submodule work tree isn't removed ...
if test "$KNOWN_FAILURE_NOFF_MERGE_ATTEMPTS_TO_MERGE_REMOVED_SUBMODULE_FILES" = 1
then
# Non fast-forward merges attempt to merge the former
# submodule files with the newly checked out ones in the
# directory of the same name while it shouldn't.
RESULT="failure"
elif test "$KNOWN_FAILURE_FORCED_SWITCH_TESTS" = 1
then
# All existing tests that use test_submodule_forced_switch()
# require this.
RESULT="failure"
else
RESULT="success"
fi
test_expect_$RESULT "$command: replace submodule with a directory must fail" '
submodules: add the lib-submodule-update.sh test library Add this test library to simplify covering all combinations of submodule update scenarios without having to add those to a test of each work tree manipulating command over and over again. The functions test_submodule_switch() and test_submodule_forced_switch() are intended to be called from a test script with a single argument. This argument is either a work tree manipulating command (including any command line options) or a function (when more than a single git command is needed to switch work trees from the current HEAD to another commit). This command (or function) is passed a target branch as argument. The two new functions check that each submodule transition is handled as expected, which currently means that submodule work trees are not affected until "git submodule update" is called. The "forced" variant is for commands using their '-f' or '--hard' option and expects them to overwrite local modifications as a result. Each of these two functions contains 14 tests_expect_* calls. Calling one of these test functions the first time creates a repository named "submodule_update_repo". At first it contains two files, then a single submodule is added in another commit followed by commits covering all relevant submodule modifications. This repository is newly cloned into the "submodule_update" for each test_expect_* to avoid interference between different parts of the test functions (some to-be-tested commands also manipulate refs along with the work tree, e.g. "git reset"). Follow-up commits will then call these two test functions for all work tree manipulating commands (with a combination of all their options relevant to what they do with the work tree) making sure they work as expected. Later this test library will be extended to cover merges resulting in conflicts too. Also it is intended to be easily extendable for the recursive update functionality, where even more combinations of submodule modifications have to be tested for. This version documents two bugs in current Git with expected failures: *) When a submodule is replaced with a tracked file of the same name the submodule work tree including any local modifications (and even the whole history if it uses a .git directory instead of a gitfile!) is silently removed. *) Forced work tree updates happily manipulate files in the directory of a submodule that has just been removed in the superproject (but is of course still present in the work tree due to the way submodules are currently handled). This becomes dangerous when files in the submodule directory are overwritten by files from the new superproject commit, as any modifications to the submodule files will be lost) and is expected to also destroy history in the - admittedly unlikely case - the new commit adds a file named ".git" to the submodule directory. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-07-01 23:24:14 +02:00
prolog &&
reset_work_tree_to add_sub1 &&
(
cd submodule_update &&
git branch -t replace_sub1_with_directory origin/replace_sub1_with_directory &&
lib-submodule-update: pass 'test_must_fail' as an argument When we run a test helper function in test_submodule_switch_common(), we sometimes specify a whole helper function as the $command. When we do this, in some test cases, we just mark the whole function with `test_must_fail`. However, it's possible that the helper function might fail earlier or later than expected due to an introduced bug. If this happens, then the test case will still report as passing but it should really be marked as failing since it didn't actually display the intended behaviour. Instead of invoking `test_must_fail $command`, pass the string "test_must_fail" as the second argument in case where the git command is expected to fail. When $command is a helper function, the parent function calling test_submodule_switch_common() is test_submodule_switch_func(). For all test_submodule_switch_func() invocations, increase the granularity of the argument test helper function by prefixing the git invocation which is meant to fail with the second argument like this: $2 git checkout "$1" In the other cases, test_submodule_switch() and test_submodule_forced_switch(), instead of passing in the git command directly, wrap it using the git_test_func() and pass the git arguments using the global variable $gitcmd. Unfortunately, since closures aren't a thing in shell scripts, the global variable is necessary. Another unfortunate result is that the "git_test_func" will used as the test case name when $command is printed but it's worth it for the cleaner code. Finally, as an added bonus, `test_must_fail` will now only run on git commands. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-24 10:50:18 +02:00
$command replace_sub1_with_directory test_must_fail &&
submodules: add the lib-submodule-update.sh test library Add this test library to simplify covering all combinations of submodule update scenarios without having to add those to a test of each work tree manipulating command over and over again. The functions test_submodule_switch() and test_submodule_forced_switch() are intended to be called from a test script with a single argument. This argument is either a work tree manipulating command (including any command line options) or a function (when more than a single git command is needed to switch work trees from the current HEAD to another commit). This command (or function) is passed a target branch as argument. The two new functions check that each submodule transition is handled as expected, which currently means that submodule work trees are not affected until "git submodule update" is called. The "forced" variant is for commands using their '-f' or '--hard' option and expects them to overwrite local modifications as a result. Each of these two functions contains 14 tests_expect_* calls. Calling one of these test functions the first time creates a repository named "submodule_update_repo". At first it contains two files, then a single submodule is added in another commit followed by commits covering all relevant submodule modifications. This repository is newly cloned into the "submodule_update" for each test_expect_* to avoid interference between different parts of the test functions (some to-be-tested commands also manipulate refs along with the work tree, e.g. "git reset"). Follow-up commits will then call these two test functions for all work tree manipulating commands (with a combination of all their options relevant to what they do with the work tree) making sure they work as expected. Later this test library will be extended to cover merges resulting in conflicts too. Also it is intended to be easily extendable for the recursive update functionality, where even more combinations of submodule modifications have to be tested for. This version documents two bugs in current Git with expected failures: *) When a submodule is replaced with a tracked file of the same name the submodule work tree including any local modifications (and even the whole history if it uses a .git directory instead of a gitfile!) is silently removed. *) Forced work tree updates happily manipulate files in the directory of a submodule that has just been removed in the superproject (but is of course still present in the work tree due to the way submodules are currently handled). This becomes dangerous when files in the submodule directory are overwritten by files from the new superproject commit, as any modifications to the submodule files will be lost) and is expected to also destroy history in the - admittedly unlikely case - the new commit adds a file named ".git" to the submodule directory. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-07-01 23:24:14 +02:00
test_superproject_content origin/add_sub1 &&
test_submodule_content sub1 origin/add_sub1
)
'
# ... especially when it contains a .git directory.
test_expect_$RESULT "$command: replace submodule containing a .git directory with a directory must fail" '
submodules: add the lib-submodule-update.sh test library Add this test library to simplify covering all combinations of submodule update scenarios without having to add those to a test of each work tree manipulating command over and over again. The functions test_submodule_switch() and test_submodule_forced_switch() are intended to be called from a test script with a single argument. This argument is either a work tree manipulating command (including any command line options) or a function (when more than a single git command is needed to switch work trees from the current HEAD to another commit). This command (or function) is passed a target branch as argument. The two new functions check that each submodule transition is handled as expected, which currently means that submodule work trees are not affected until "git submodule update" is called. The "forced" variant is for commands using their '-f' or '--hard' option and expects them to overwrite local modifications as a result. Each of these two functions contains 14 tests_expect_* calls. Calling one of these test functions the first time creates a repository named "submodule_update_repo". At first it contains two files, then a single submodule is added in another commit followed by commits covering all relevant submodule modifications. This repository is newly cloned into the "submodule_update" for each test_expect_* to avoid interference between different parts of the test functions (some to-be-tested commands also manipulate refs along with the work tree, e.g. "git reset"). Follow-up commits will then call these two test functions for all work tree manipulating commands (with a combination of all their options relevant to what they do with the work tree) making sure they work as expected. Later this test library will be extended to cover merges resulting in conflicts too. Also it is intended to be easily extendable for the recursive update functionality, where even more combinations of submodule modifications have to be tested for. This version documents two bugs in current Git with expected failures: *) When a submodule is replaced with a tracked file of the same name the submodule work tree including any local modifications (and even the whole history if it uses a .git directory instead of a gitfile!) is silently removed. *) Forced work tree updates happily manipulate files in the directory of a submodule that has just been removed in the superproject (but is of course still present in the work tree due to the way submodules are currently handled). This becomes dangerous when files in the submodule directory are overwritten by files from the new superproject commit, as any modifications to the submodule files will be lost) and is expected to also destroy history in the - admittedly unlikely case - the new commit adds a file named ".git" to the submodule directory. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-07-01 23:24:14 +02:00
prolog &&
reset_work_tree_to add_sub1 &&
(
cd submodule_update &&
git branch -t replace_sub1_with_directory origin/replace_sub1_with_directory &&
replace_gitfile_with_git_dir sub1 &&
lib-submodule-update: pass 'test_must_fail' as an argument When we run a test helper function in test_submodule_switch_common(), we sometimes specify a whole helper function as the $command. When we do this, in some test cases, we just mark the whole function with `test_must_fail`. However, it's possible that the helper function might fail earlier or later than expected due to an introduced bug. If this happens, then the test case will still report as passing but it should really be marked as failing since it didn't actually display the intended behaviour. Instead of invoking `test_must_fail $command`, pass the string "test_must_fail" as the second argument in case where the git command is expected to fail. When $command is a helper function, the parent function calling test_submodule_switch_common() is test_submodule_switch_func(). For all test_submodule_switch_func() invocations, increase the granularity of the argument test helper function by prefixing the git invocation which is meant to fail with the second argument like this: $2 git checkout "$1" In the other cases, test_submodule_switch() and test_submodule_forced_switch(), instead of passing in the git command directly, wrap it using the git_test_func() and pass the git arguments using the global variable $gitcmd. Unfortunately, since closures aren't a thing in shell scripts, the global variable is necessary. Another unfortunate result is that the "git_test_func" will used as the test case name when $command is printed but it's worth it for the cleaner code. Finally, as an added bonus, `test_must_fail` will now only run on git commands. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-24 10:50:18 +02:00
$command replace_sub1_with_directory test_must_fail &&
submodules: add the lib-submodule-update.sh test library Add this test library to simplify covering all combinations of submodule update scenarios without having to add those to a test of each work tree manipulating command over and over again. The functions test_submodule_switch() and test_submodule_forced_switch() are intended to be called from a test script with a single argument. This argument is either a work tree manipulating command (including any command line options) or a function (when more than a single git command is needed to switch work trees from the current HEAD to another commit). This command (or function) is passed a target branch as argument. The two new functions check that each submodule transition is handled as expected, which currently means that submodule work trees are not affected until "git submodule update" is called. The "forced" variant is for commands using their '-f' or '--hard' option and expects them to overwrite local modifications as a result. Each of these two functions contains 14 tests_expect_* calls. Calling one of these test functions the first time creates a repository named "submodule_update_repo". At first it contains two files, then a single submodule is added in another commit followed by commits covering all relevant submodule modifications. This repository is newly cloned into the "submodule_update" for each test_expect_* to avoid interference between different parts of the test functions (some to-be-tested commands also manipulate refs along with the work tree, e.g. "git reset"). Follow-up commits will then call these two test functions for all work tree manipulating commands (with a combination of all their options relevant to what they do with the work tree) making sure they work as expected. Later this test library will be extended to cover merges resulting in conflicts too. Also it is intended to be easily extendable for the recursive update functionality, where even more combinations of submodule modifications have to be tested for. This version documents two bugs in current Git with expected failures: *) When a submodule is replaced with a tracked file of the same name the submodule work tree including any local modifications (and even the whole history if it uses a .git directory instead of a gitfile!) is silently removed. *) Forced work tree updates happily manipulate files in the directory of a submodule that has just been removed in the superproject (but is of course still present in the work tree due to the way submodules are currently handled). This becomes dangerous when files in the submodule directory are overwritten by files from the new superproject commit, as any modifications to the submodule files will be lost) and is expected to also destroy history in the - admittedly unlikely case - the new commit adds a file named ".git" to the submodule directory. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-07-01 23:24:14 +02:00
test_superproject_content origin/add_sub1 &&
test_git_directory_is_unchanged sub1 &&
test_submodule_content sub1 origin/add_sub1
)
'
# Replacing it with a file must fail as it could throw away any local
# work tree changes ...
test_expect_failure "$command: replace submodule with a file must fail" '
prolog &&
reset_work_tree_to add_sub1 &&
(
cd submodule_update &&
git branch -t replace_sub1_with_file origin/replace_sub1_with_file &&
lib-submodule-update: pass 'test_must_fail' as an argument When we run a test helper function in test_submodule_switch_common(), we sometimes specify a whole helper function as the $command. When we do this, in some test cases, we just mark the whole function with `test_must_fail`. However, it's possible that the helper function might fail earlier or later than expected due to an introduced bug. If this happens, then the test case will still report as passing but it should really be marked as failing since it didn't actually display the intended behaviour. Instead of invoking `test_must_fail $command`, pass the string "test_must_fail" as the second argument in case where the git command is expected to fail. When $command is a helper function, the parent function calling test_submodule_switch_common() is test_submodule_switch_func(). For all test_submodule_switch_func() invocations, increase the granularity of the argument test helper function by prefixing the git invocation which is meant to fail with the second argument like this: $2 git checkout "$1" In the other cases, test_submodule_switch() and test_submodule_forced_switch(), instead of passing in the git command directly, wrap it using the git_test_func() and pass the git arguments using the global variable $gitcmd. Unfortunately, since closures aren't a thing in shell scripts, the global variable is necessary. Another unfortunate result is that the "git_test_func" will used as the test case name when $command is printed but it's worth it for the cleaner code. Finally, as an added bonus, `test_must_fail` will now only run on git commands. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-24 10:50:18 +02:00
$command replace_sub1_with_file test_must_fail &&
submodules: add the lib-submodule-update.sh test library Add this test library to simplify covering all combinations of submodule update scenarios without having to add those to a test of each work tree manipulating command over and over again. The functions test_submodule_switch() and test_submodule_forced_switch() are intended to be called from a test script with a single argument. This argument is either a work tree manipulating command (including any command line options) or a function (when more than a single git command is needed to switch work trees from the current HEAD to another commit). This command (or function) is passed a target branch as argument. The two new functions check that each submodule transition is handled as expected, which currently means that submodule work trees are not affected until "git submodule update" is called. The "forced" variant is for commands using their '-f' or '--hard' option and expects them to overwrite local modifications as a result. Each of these two functions contains 14 tests_expect_* calls. Calling one of these test functions the first time creates a repository named "submodule_update_repo". At first it contains two files, then a single submodule is added in another commit followed by commits covering all relevant submodule modifications. This repository is newly cloned into the "submodule_update" for each test_expect_* to avoid interference between different parts of the test functions (some to-be-tested commands also manipulate refs along with the work tree, e.g. "git reset"). Follow-up commits will then call these two test functions for all work tree manipulating commands (with a combination of all their options relevant to what they do with the work tree) making sure they work as expected. Later this test library will be extended to cover merges resulting in conflicts too. Also it is intended to be easily extendable for the recursive update functionality, where even more combinations of submodule modifications have to be tested for. This version documents two bugs in current Git with expected failures: *) When a submodule is replaced with a tracked file of the same name the submodule work tree including any local modifications (and even the whole history if it uses a .git directory instead of a gitfile!) is silently removed. *) Forced work tree updates happily manipulate files in the directory of a submodule that has just been removed in the superproject (but is of course still present in the work tree due to the way submodules are currently handled). This becomes dangerous when files in the submodule directory are overwritten by files from the new superproject commit, as any modifications to the submodule files will be lost) and is expected to also destroy history in the - admittedly unlikely case - the new commit adds a file named ".git" to the submodule directory. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-07-01 23:24:14 +02:00
test_superproject_content origin/add_sub1 &&
test_submodule_content sub1 origin/add_sub1
)
'
# ... or even destroy unpushed parts of submodule history if that
# still uses a .git directory.
test_expect_failure "$command: replace submodule containing a .git directory with a file must fail" '
prolog &&
reset_work_tree_to add_sub1 &&
(
cd submodule_update &&
git branch -t replace_sub1_with_file origin/replace_sub1_with_file &&
replace_gitfile_with_git_dir sub1 &&
lib-submodule-update: pass 'test_must_fail' as an argument When we run a test helper function in test_submodule_switch_common(), we sometimes specify a whole helper function as the $command. When we do this, in some test cases, we just mark the whole function with `test_must_fail`. However, it's possible that the helper function might fail earlier or later than expected due to an introduced bug. If this happens, then the test case will still report as passing but it should really be marked as failing since it didn't actually display the intended behaviour. Instead of invoking `test_must_fail $command`, pass the string "test_must_fail" as the second argument in case where the git command is expected to fail. When $command is a helper function, the parent function calling test_submodule_switch_common() is test_submodule_switch_func(). For all test_submodule_switch_func() invocations, increase the granularity of the argument test helper function by prefixing the git invocation which is meant to fail with the second argument like this: $2 git checkout "$1" In the other cases, test_submodule_switch() and test_submodule_forced_switch(), instead of passing in the git command directly, wrap it using the git_test_func() and pass the git arguments using the global variable $gitcmd. Unfortunately, since closures aren't a thing in shell scripts, the global variable is necessary. Another unfortunate result is that the "git_test_func" will used as the test case name when $command is printed but it's worth it for the cleaner code. Finally, as an added bonus, `test_must_fail` will now only run on git commands. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-24 10:50:18 +02:00
$command replace_sub1_with_file test_must_fail &&
submodules: add the lib-submodule-update.sh test library Add this test library to simplify covering all combinations of submodule update scenarios without having to add those to a test of each work tree manipulating command over and over again. The functions test_submodule_switch() and test_submodule_forced_switch() are intended to be called from a test script with a single argument. This argument is either a work tree manipulating command (including any command line options) or a function (when more than a single git command is needed to switch work trees from the current HEAD to another commit). This command (or function) is passed a target branch as argument. The two new functions check that each submodule transition is handled as expected, which currently means that submodule work trees are not affected until "git submodule update" is called. The "forced" variant is for commands using their '-f' or '--hard' option and expects them to overwrite local modifications as a result. Each of these two functions contains 14 tests_expect_* calls. Calling one of these test functions the first time creates a repository named "submodule_update_repo". At first it contains two files, then a single submodule is added in another commit followed by commits covering all relevant submodule modifications. This repository is newly cloned into the "submodule_update" for each test_expect_* to avoid interference between different parts of the test functions (some to-be-tested commands also manipulate refs along with the work tree, e.g. "git reset"). Follow-up commits will then call these two test functions for all work tree manipulating commands (with a combination of all their options relevant to what they do with the work tree) making sure they work as expected. Later this test library will be extended to cover merges resulting in conflicts too. Also it is intended to be easily extendable for the recursive update functionality, where even more combinations of submodule modifications have to be tested for. This version documents two bugs in current Git with expected failures: *) When a submodule is replaced with a tracked file of the same name the submodule work tree including any local modifications (and even the whole history if it uses a .git directory instead of a gitfile!) is silently removed. *) Forced work tree updates happily manipulate files in the directory of a submodule that has just been removed in the superproject (but is of course still present in the work tree due to the way submodules are currently handled). This becomes dangerous when files in the submodule directory are overwritten by files from the new superproject commit, as any modifications to the submodule files will be lost) and is expected to also destroy history in the - admittedly unlikely case - the new commit adds a file named ".git" to the submodule directory. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-07-01 23:24:14 +02:00
test_superproject_content origin/add_sub1 &&
test_git_directory_is_unchanged sub1 &&
test_submodule_content sub1 origin/add_sub1
)
'
########################## Modified submodule #########################
# Updating a submodule sha1 doesn't update the submodule's work tree
if test "$KNOWN_FAILURE_CHERRY_PICK_SEES_EMPTY_COMMIT" = 1
then
# When cherry picking a SHA-1 update for an ignored submodule
# the commit incorrectly fails with "The previous cherry-pick
# is now empty, possibly due to conflict resolution."
RESULT="failure"
else
RESULT="success"
fi
test_expect_$RESULT "$command: modified submodule does not update submodule work tree" '
submodules: add the lib-submodule-update.sh test library Add this test library to simplify covering all combinations of submodule update scenarios without having to add those to a test of each work tree manipulating command over and over again. The functions test_submodule_switch() and test_submodule_forced_switch() are intended to be called from a test script with a single argument. This argument is either a work tree manipulating command (including any command line options) or a function (when more than a single git command is needed to switch work trees from the current HEAD to another commit). This command (or function) is passed a target branch as argument. The two new functions check that each submodule transition is handled as expected, which currently means that submodule work trees are not affected until "git submodule update" is called. The "forced" variant is for commands using their '-f' or '--hard' option and expects them to overwrite local modifications as a result. Each of these two functions contains 14 tests_expect_* calls. Calling one of these test functions the first time creates a repository named "submodule_update_repo". At first it contains two files, then a single submodule is added in another commit followed by commits covering all relevant submodule modifications. This repository is newly cloned into the "submodule_update" for each test_expect_* to avoid interference between different parts of the test functions (some to-be-tested commands also manipulate refs along with the work tree, e.g. "git reset"). Follow-up commits will then call these two test functions for all work tree manipulating commands (with a combination of all their options relevant to what they do with the work tree) making sure they work as expected. Later this test library will be extended to cover merges resulting in conflicts too. Also it is intended to be easily extendable for the recursive update functionality, where even more combinations of submodule modifications have to be tested for. This version documents two bugs in current Git with expected failures: *) When a submodule is replaced with a tracked file of the same name the submodule work tree including any local modifications (and even the whole history if it uses a .git directory instead of a gitfile!) is silently removed. *) Forced work tree updates happily manipulate files in the directory of a submodule that has just been removed in the superproject (but is of course still present in the work tree due to the way submodules are currently handled). This becomes dangerous when files in the submodule directory are overwritten by files from the new superproject commit, as any modifications to the submodule files will be lost) and is expected to also destroy history in the - admittedly unlikely case - the new commit adds a file named ".git" to the submodule directory. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-07-01 23:24:14 +02:00
prolog &&
reset_work_tree_to add_sub1 &&
(
cd submodule_update &&
git branch -t modify_sub1 origin/modify_sub1 &&
$command modify_sub1 &&
test_superproject_content origin/modify_sub1 &&
test_submodule_content sub1 origin/add_sub1 &&
git submodule update &&
test_submodule_content sub1 origin/modify_sub1
)
'
# Updating a submodule to an invalid sha1 doesn't update the
# submodule's work tree, subsequent update will fail
test_expect_$RESULT "$command: modified submodule does not update submodule work tree to invalid commit" '
submodules: add the lib-submodule-update.sh test library Add this test library to simplify covering all combinations of submodule update scenarios without having to add those to a test of each work tree manipulating command over and over again. The functions test_submodule_switch() and test_submodule_forced_switch() are intended to be called from a test script with a single argument. This argument is either a work tree manipulating command (including any command line options) or a function (when more than a single git command is needed to switch work trees from the current HEAD to another commit). This command (or function) is passed a target branch as argument. The two new functions check that each submodule transition is handled as expected, which currently means that submodule work trees are not affected until "git submodule update" is called. The "forced" variant is for commands using their '-f' or '--hard' option and expects them to overwrite local modifications as a result. Each of these two functions contains 14 tests_expect_* calls. Calling one of these test functions the first time creates a repository named "submodule_update_repo". At first it contains two files, then a single submodule is added in another commit followed by commits covering all relevant submodule modifications. This repository is newly cloned into the "submodule_update" for each test_expect_* to avoid interference between different parts of the test functions (some to-be-tested commands also manipulate refs along with the work tree, e.g. "git reset"). Follow-up commits will then call these two test functions for all work tree manipulating commands (with a combination of all their options relevant to what they do with the work tree) making sure they work as expected. Later this test library will be extended to cover merges resulting in conflicts too. Also it is intended to be easily extendable for the recursive update functionality, where even more combinations of submodule modifications have to be tested for. This version documents two bugs in current Git with expected failures: *) When a submodule is replaced with a tracked file of the same name the submodule work tree including any local modifications (and even the whole history if it uses a .git directory instead of a gitfile!) is silently removed. *) Forced work tree updates happily manipulate files in the directory of a submodule that has just been removed in the superproject (but is of course still present in the work tree due to the way submodules are currently handled). This becomes dangerous when files in the submodule directory are overwritten by files from the new superproject commit, as any modifications to the submodule files will be lost) and is expected to also destroy history in the - admittedly unlikely case - the new commit adds a file named ".git" to the submodule directory. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-07-01 23:24:14 +02:00
prolog &&
reset_work_tree_to add_sub1 &&
(
cd submodule_update &&
git branch -t invalid_sub1 origin/invalid_sub1 &&
$command invalid_sub1 &&
test_superproject_content origin/invalid_sub1 &&
test_submodule_content sub1 origin/add_sub1 &&
test_must_fail git submodule update &&
test_submodule_content sub1 origin/add_sub1
)
'
# Updating a submodule from an invalid sha1 doesn't update the
# submodule's work tree, subsequent update will succeed
test_expect_$RESULT "$command: modified submodule does not update submodule work tree from invalid commit" '
submodules: add the lib-submodule-update.sh test library Add this test library to simplify covering all combinations of submodule update scenarios without having to add those to a test of each work tree manipulating command over and over again. The functions test_submodule_switch() and test_submodule_forced_switch() are intended to be called from a test script with a single argument. This argument is either a work tree manipulating command (including any command line options) or a function (when more than a single git command is needed to switch work trees from the current HEAD to another commit). This command (or function) is passed a target branch as argument. The two new functions check that each submodule transition is handled as expected, which currently means that submodule work trees are not affected until "git submodule update" is called. The "forced" variant is for commands using their '-f' or '--hard' option and expects them to overwrite local modifications as a result. Each of these two functions contains 14 tests_expect_* calls. Calling one of these test functions the first time creates a repository named "submodule_update_repo". At first it contains two files, then a single submodule is added in another commit followed by commits covering all relevant submodule modifications. This repository is newly cloned into the "submodule_update" for each test_expect_* to avoid interference between different parts of the test functions (some to-be-tested commands also manipulate refs along with the work tree, e.g. "git reset"). Follow-up commits will then call these two test functions for all work tree manipulating commands (with a combination of all their options relevant to what they do with the work tree) making sure they work as expected. Later this test library will be extended to cover merges resulting in conflicts too. Also it is intended to be easily extendable for the recursive update functionality, where even more combinations of submodule modifications have to be tested for. This version documents two bugs in current Git with expected failures: *) When a submodule is replaced with a tracked file of the same name the submodule work tree including any local modifications (and even the whole history if it uses a .git directory instead of a gitfile!) is silently removed. *) Forced work tree updates happily manipulate files in the directory of a submodule that has just been removed in the superproject (but is of course still present in the work tree due to the way submodules are currently handled). This becomes dangerous when files in the submodule directory are overwritten by files from the new superproject commit, as any modifications to the submodule files will be lost) and is expected to also destroy history in the - admittedly unlikely case - the new commit adds a file named ".git" to the submodule directory. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-07-01 23:24:14 +02:00
prolog &&
reset_work_tree_to invalid_sub1 &&
(
cd submodule_update &&
git branch -t valid_sub1 origin/valid_sub1 &&
$command valid_sub1 &&
test_superproject_content origin/valid_sub1 &&
test_dir_is_empty sub1 &&
git submodule update --init --recursive &&
test_submodule_content sub1 origin/valid_sub1
)
'
}
# Declares and invokes several tests that, in various situations, checks that
# the provided transition function:
# - succeeds in updating the worktree and index of a superproject to a target
# commit, or fails atomically (depending on the test situation)
# - if succeeds, the contents of submodule directories are unchanged
# - if succeeds, once "git submodule update" is invoked, the contents of
# submodule directories are updated
#
# If the command under test is known to not work with submodules in certain
# conditions, set the appropriate KNOWN_FAILURE_* variable used in the tests
# below to 1.
#
lib-submodule-update: pass 'test_must_fail' as an argument When we run a test helper function in test_submodule_switch_common(), we sometimes specify a whole helper function as the $command. When we do this, in some test cases, we just mark the whole function with `test_must_fail`. However, it's possible that the helper function might fail earlier or later than expected due to an introduced bug. If this happens, then the test case will still report as passing but it should really be marked as failing since it didn't actually display the intended behaviour. Instead of invoking `test_must_fail $command`, pass the string "test_must_fail" as the second argument in case where the git command is expected to fail. When $command is a helper function, the parent function calling test_submodule_switch_common() is test_submodule_switch_func(). For all test_submodule_switch_func() invocations, increase the granularity of the argument test helper function by prefixing the git invocation which is meant to fail with the second argument like this: $2 git checkout "$1" In the other cases, test_submodule_switch() and test_submodule_forced_switch(), instead of passing in the git command directly, wrap it using the git_test_func() and pass the git arguments using the global variable $gitcmd. Unfortunately, since closures aren't a thing in shell scripts, the global variable is necessary. Another unfortunate result is that the "git_test_func" will used as the test case name when $command is printed but it's worth it for the cleaner code. Finally, as an added bonus, `test_must_fail` will now only run on git commands. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-24 10:50:18 +02:00
# The first argument of the callback function will be the name of the submodule.
#
# Removing a submodule containing a .git directory must fail even when forced
# to protect the history! If we are testing this case, the second argument of
# the callback function will be 'test_must_fail', else it will be the empty
# string.
#
# The following example uses `git some-command` as an example command to be
# tested. It updates the worktree and index to match a target, but not any
# submodule directories.
#
# my_func () {
lib-submodule-update: pass 'test_must_fail' as an argument When we run a test helper function in test_submodule_switch_common(), we sometimes specify a whole helper function as the $command. When we do this, in some test cases, we just mark the whole function with `test_must_fail`. However, it's possible that the helper function might fail earlier or later than expected due to an introduced bug. If this happens, then the test case will still report as passing but it should really be marked as failing since it didn't actually display the intended behaviour. Instead of invoking `test_must_fail $command`, pass the string "test_must_fail" as the second argument in case where the git command is expected to fail. When $command is a helper function, the parent function calling test_submodule_switch_common() is test_submodule_switch_func(). For all test_submodule_switch_func() invocations, increase the granularity of the argument test helper function by prefixing the git invocation which is meant to fail with the second argument like this: $2 git checkout "$1" In the other cases, test_submodule_switch() and test_submodule_forced_switch(), instead of passing in the git command directly, wrap it using the git_test_func() and pass the git arguments using the global variable $gitcmd. Unfortunately, since closures aren't a thing in shell scripts, the global variable is necessary. Another unfortunate result is that the "git_test_func" will used as the test case name when $command is printed but it's worth it for the cleaner code. Finally, as an added bonus, `test_must_fail` will now only run on git commands. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-24 10:50:18 +02:00
# ...prepare for `git some-command` to be run...
# $2 git some-command "$1" &&
# if test -n "$2"
# then
# return
# fi &&
# ...check the state after git some-command is run...
# }
# test_submodule_switch_func "my_func"
test_submodule_switch_func () {
submodules: add the lib-submodule-update.sh test library Add this test library to simplify covering all combinations of submodule update scenarios without having to add those to a test of each work tree manipulating command over and over again. The functions test_submodule_switch() and test_submodule_forced_switch() are intended to be called from a test script with a single argument. This argument is either a work tree manipulating command (including any command line options) or a function (when more than a single git command is needed to switch work trees from the current HEAD to another commit). This command (or function) is passed a target branch as argument. The two new functions check that each submodule transition is handled as expected, which currently means that submodule work trees are not affected until "git submodule update" is called. The "forced" variant is for commands using their '-f' or '--hard' option and expects them to overwrite local modifications as a result. Each of these two functions contains 14 tests_expect_* calls. Calling one of these test functions the first time creates a repository named "submodule_update_repo". At first it contains two files, then a single submodule is added in another commit followed by commits covering all relevant submodule modifications. This repository is newly cloned into the "submodule_update" for each test_expect_* to avoid interference between different parts of the test functions (some to-be-tested commands also manipulate refs along with the work tree, e.g. "git reset"). Follow-up commits will then call these two test functions for all work tree manipulating commands (with a combination of all their options relevant to what they do with the work tree) making sure they work as expected. Later this test library will be extended to cover merges resulting in conflicts too. Also it is intended to be easily extendable for the recursive update functionality, where even more combinations of submodule modifications have to be tested for. This version documents two bugs in current Git with expected failures: *) When a submodule is replaced with a tracked file of the same name the submodule work tree including any local modifications (and even the whole history if it uses a .git directory instead of a gitfile!) is silently removed. *) Forced work tree updates happily manipulate files in the directory of a submodule that has just been removed in the superproject (but is of course still present in the work tree due to the way submodules are currently handled). This becomes dangerous when files in the submodule directory are overwritten by files from the new superproject commit, as any modifications to the submodule files will be lost) and is expected to also destroy history in the - admittedly unlikely case - the new commit adds a file named ".git" to the submodule directory. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-07-01 23:24:14 +02:00
command="$1"
test_submodule_switch_common "$command"
# An empty directory does not prevent the creation of a submodule of
# the same name, but a file does.
test_expect_success "$command: added submodule doesn't remove untracked unignored file with same name" '
submodules: add the lib-submodule-update.sh test library Add this test library to simplify covering all combinations of submodule update scenarios without having to add those to a test of each work tree manipulating command over and over again. The functions test_submodule_switch() and test_submodule_forced_switch() are intended to be called from a test script with a single argument. This argument is either a work tree manipulating command (including any command line options) or a function (when more than a single git command is needed to switch work trees from the current HEAD to another commit). This command (or function) is passed a target branch as argument. The two new functions check that each submodule transition is handled as expected, which currently means that submodule work trees are not affected until "git submodule update" is called. The "forced" variant is for commands using their '-f' or '--hard' option and expects them to overwrite local modifications as a result. Each of these two functions contains 14 tests_expect_* calls. Calling one of these test functions the first time creates a repository named "submodule_update_repo". At first it contains two files, then a single submodule is added in another commit followed by commits covering all relevant submodule modifications. This repository is newly cloned into the "submodule_update" for each test_expect_* to avoid interference between different parts of the test functions (some to-be-tested commands also manipulate refs along with the work tree, e.g. "git reset"). Follow-up commits will then call these two test functions for all work tree manipulating commands (with a combination of all their options relevant to what they do with the work tree) making sure they work as expected. Later this test library will be extended to cover merges resulting in conflicts too. Also it is intended to be easily extendable for the recursive update functionality, where even more combinations of submodule modifications have to be tested for. This version documents two bugs in current Git with expected failures: *) When a submodule is replaced with a tracked file of the same name the submodule work tree including any local modifications (and even the whole history if it uses a .git directory instead of a gitfile!) is silently removed. *) Forced work tree updates happily manipulate files in the directory of a submodule that has just been removed in the superproject (but is of course still present in the work tree due to the way submodules are currently handled). This becomes dangerous when files in the submodule directory are overwritten by files from the new superproject commit, as any modifications to the submodule files will be lost) and is expected to also destroy history in the - admittedly unlikely case - the new commit adds a file named ".git" to the submodule directory. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-07-01 23:24:14 +02:00
prolog &&
reset_work_tree_to no_submodule &&
(
cd submodule_update &&
git branch -t add_sub1 origin/add_sub1 &&
>sub1 &&
lib-submodule-update: pass 'test_must_fail' as an argument When we run a test helper function in test_submodule_switch_common(), we sometimes specify a whole helper function as the $command. When we do this, in some test cases, we just mark the whole function with `test_must_fail`. However, it's possible that the helper function might fail earlier or later than expected due to an introduced bug. If this happens, then the test case will still report as passing but it should really be marked as failing since it didn't actually display the intended behaviour. Instead of invoking `test_must_fail $command`, pass the string "test_must_fail" as the second argument in case where the git command is expected to fail. When $command is a helper function, the parent function calling test_submodule_switch_common() is test_submodule_switch_func(). For all test_submodule_switch_func() invocations, increase the granularity of the argument test helper function by prefixing the git invocation which is meant to fail with the second argument like this: $2 git checkout "$1" In the other cases, test_submodule_switch() and test_submodule_forced_switch(), instead of passing in the git command directly, wrap it using the git_test_func() and pass the git arguments using the global variable $gitcmd. Unfortunately, since closures aren't a thing in shell scripts, the global variable is necessary. Another unfortunate result is that the "git_test_func" will used as the test case name when $command is printed but it's worth it for the cleaner code. Finally, as an added bonus, `test_must_fail` will now only run on git commands. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-24 10:50:18 +02:00
$command add_sub1 test_must_fail &&
test_superproject_content origin/no_submodule &&
test_must_be_empty sub1
submodules: add the lib-submodule-update.sh test library Add this test library to simplify covering all combinations of submodule update scenarios without having to add those to a test of each work tree manipulating command over and over again. The functions test_submodule_switch() and test_submodule_forced_switch() are intended to be called from a test script with a single argument. This argument is either a work tree manipulating command (including any command line options) or a function (when more than a single git command is needed to switch work trees from the current HEAD to another commit). This command (or function) is passed a target branch as argument. The two new functions check that each submodule transition is handled as expected, which currently means that submodule work trees are not affected until "git submodule update" is called. The "forced" variant is for commands using their '-f' or '--hard' option and expects them to overwrite local modifications as a result. Each of these two functions contains 14 tests_expect_* calls. Calling one of these test functions the first time creates a repository named "submodule_update_repo". At first it contains two files, then a single submodule is added in another commit followed by commits covering all relevant submodule modifications. This repository is newly cloned into the "submodule_update" for each test_expect_* to avoid interference between different parts of the test functions (some to-be-tested commands also manipulate refs along with the work tree, e.g. "git reset"). Follow-up commits will then call these two test functions for all work tree manipulating commands (with a combination of all their options relevant to what they do with the work tree) making sure they work as expected. Later this test library will be extended to cover merges resulting in conflicts too. Also it is intended to be easily extendable for the recursive update functionality, where even more combinations of submodule modifications have to be tested for. This version documents two bugs in current Git with expected failures: *) When a submodule is replaced with a tracked file of the same name the submodule work tree including any local modifications (and even the whole history if it uses a .git directory instead of a gitfile!) is silently removed. *) Forced work tree updates happily manipulate files in the directory of a submodule that has just been removed in the superproject (but is of course still present in the work tree due to the way submodules are currently handled). This becomes dangerous when files in the submodule directory are overwritten by files from the new superproject commit, as any modifications to the submodule files will be lost) and is expected to also destroy history in the - admittedly unlikely case - the new commit adds a file named ".git" to the submodule directory. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-07-01 23:24:14 +02:00
)
'
}
lib-submodule-update: pass 'test_must_fail' as an argument When we run a test helper function in test_submodule_switch_common(), we sometimes specify a whole helper function as the $command. When we do this, in some test cases, we just mark the whole function with `test_must_fail`. However, it's possible that the helper function might fail earlier or later than expected due to an introduced bug. If this happens, then the test case will still report as passing but it should really be marked as failing since it didn't actually display the intended behaviour. Instead of invoking `test_must_fail $command`, pass the string "test_must_fail" as the second argument in case where the git command is expected to fail. When $command is a helper function, the parent function calling test_submodule_switch_common() is test_submodule_switch_func(). For all test_submodule_switch_func() invocations, increase the granularity of the argument test helper function by prefixing the git invocation which is meant to fail with the second argument like this: $2 git checkout "$1" In the other cases, test_submodule_switch() and test_submodule_forced_switch(), instead of passing in the git command directly, wrap it using the git_test_func() and pass the git arguments using the global variable $gitcmd. Unfortunately, since closures aren't a thing in shell scripts, the global variable is necessary. Another unfortunate result is that the "git_test_func" will used as the test case name when $command is printed but it's worth it for the cleaner code. Finally, as an added bonus, `test_must_fail` will now only run on git commands. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-24 10:50:18 +02:00
# Ensures that the that the arg either contains "test_must_fail" or is empty.
may_only_be_test_must_fail () {
test -z "$1" || test "$1" = test_must_fail || die
}
git_test_func () {
may_only_be_test_must_fail "$2" &&
$2 git $gitcmd "$1"
}
test_submodule_switch () {
lib-submodule-update: pass 'test_must_fail' as an argument When we run a test helper function in test_submodule_switch_common(), we sometimes specify a whole helper function as the $command. When we do this, in some test cases, we just mark the whole function with `test_must_fail`. However, it's possible that the helper function might fail earlier or later than expected due to an introduced bug. If this happens, then the test case will still report as passing but it should really be marked as failing since it didn't actually display the intended behaviour. Instead of invoking `test_must_fail $command`, pass the string "test_must_fail" as the second argument in case where the git command is expected to fail. When $command is a helper function, the parent function calling test_submodule_switch_common() is test_submodule_switch_func(). For all test_submodule_switch_func() invocations, increase the granularity of the argument test helper function by prefixing the git invocation which is meant to fail with the second argument like this: $2 git checkout "$1" In the other cases, test_submodule_switch() and test_submodule_forced_switch(), instead of passing in the git command directly, wrap it using the git_test_func() and pass the git arguments using the global variable $gitcmd. Unfortunately, since closures aren't a thing in shell scripts, the global variable is necessary. Another unfortunate result is that the "git_test_func" will used as the test case name when $command is printed but it's worth it for the cleaner code. Finally, as an added bonus, `test_must_fail` will now only run on git commands. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-24 10:50:18 +02:00
gitcmd="$1"
test_submodule_switch_func "git_test_func"
}
# Same as test_submodule_switch(), except that throwing away local changes in
# the superproject is allowed.
test_submodule_forced_switch () {
lib-submodule-update: pass 'test_must_fail' as an argument When we run a test helper function in test_submodule_switch_common(), we sometimes specify a whole helper function as the $command. When we do this, in some test cases, we just mark the whole function with `test_must_fail`. However, it's possible that the helper function might fail earlier or later than expected due to an introduced bug. If this happens, then the test case will still report as passing but it should really be marked as failing since it didn't actually display the intended behaviour. Instead of invoking `test_must_fail $command`, pass the string "test_must_fail" as the second argument in case where the git command is expected to fail. When $command is a helper function, the parent function calling test_submodule_switch_common() is test_submodule_switch_func(). For all test_submodule_switch_func() invocations, increase the granularity of the argument test helper function by prefixing the git invocation which is meant to fail with the second argument like this: $2 git checkout "$1" In the other cases, test_submodule_switch() and test_submodule_forced_switch(), instead of passing in the git command directly, wrap it using the git_test_func() and pass the git arguments using the global variable $gitcmd. Unfortunately, since closures aren't a thing in shell scripts, the global variable is necessary. Another unfortunate result is that the "git_test_func" will used as the test case name when $command is printed but it's worth it for the cleaner code. Finally, as an added bonus, `test_must_fail` will now only run on git commands. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-24 10:50:18 +02:00
gitcmd="$1"
command="git_test_func"
KNOWN_FAILURE_FORCED_SWITCH_TESTS=1
test_submodule_switch_common "$command"
# When forced, a file in the superproject does not prevent creating a
# submodule of the same name.
submodules: add the lib-submodule-update.sh test library Add this test library to simplify covering all combinations of submodule update scenarios without having to add those to a test of each work tree manipulating command over and over again. The functions test_submodule_switch() and test_submodule_forced_switch() are intended to be called from a test script with a single argument. This argument is either a work tree manipulating command (including any command line options) or a function (when more than a single git command is needed to switch work trees from the current HEAD to another commit). This command (or function) is passed a target branch as argument. The two new functions check that each submodule transition is handled as expected, which currently means that submodule work trees are not affected until "git submodule update" is called. The "forced" variant is for commands using their '-f' or '--hard' option and expects them to overwrite local modifications as a result. Each of these two functions contains 14 tests_expect_* calls. Calling one of these test functions the first time creates a repository named "submodule_update_repo". At first it contains two files, then a single submodule is added in another commit followed by commits covering all relevant submodule modifications. This repository is newly cloned into the "submodule_update" for each test_expect_* to avoid interference between different parts of the test functions (some to-be-tested commands also manipulate refs along with the work tree, e.g. "git reset"). Follow-up commits will then call these two test functions for all work tree manipulating commands (with a combination of all their options relevant to what they do with the work tree) making sure they work as expected. Later this test library will be extended to cover merges resulting in conflicts too. Also it is intended to be easily extendable for the recursive update functionality, where even more combinations of submodule modifications have to be tested for. This version documents two bugs in current Git with expected failures: *) When a submodule is replaced with a tracked file of the same name the submodule work tree including any local modifications (and even the whole history if it uses a .git directory instead of a gitfile!) is silently removed. *) Forced work tree updates happily manipulate files in the directory of a submodule that has just been removed in the superproject (but is of course still present in the work tree due to the way submodules are currently handled). This becomes dangerous when files in the submodule directory are overwritten by files from the new superproject commit, as any modifications to the submodule files will be lost) and is expected to also destroy history in the - admittedly unlikely case - the new commit adds a file named ".git" to the submodule directory. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-07-01 23:24:14 +02:00
test_expect_success "$command: added submodule does remove untracked unignored file with same name when forced" '
prolog &&
reset_work_tree_to no_submodule &&
(
cd submodule_update &&
git branch -t add_sub1 origin/add_sub1 &&
>sub1 &&
$command add_sub1 &&
test_superproject_content origin/add_sub1 &&
test_dir_is_empty sub1
)
'
}
# Test that submodule contents are correctly updated when switching
# between commits that change a submodule.
# Test that the following transitions are correctly handled:
# (These tests are also above in the case where we expect no change
# in the submodule)
# - Updated submodule
# - New submodule
# - Removed submodule
# - Directory containing tracked files replaced by submodule
# - Submodule replaced by tracked files in directory
# - Submodule replaced by tracked file with the same name
# - Tracked file replaced by submodule
#
# New test cases
# - Removing a submodule with a git directory absorbs the submodules
# git directory first into the superproject.
unpack-trees: check for missing submodule directory in merged_entry Using `git checkout --recurse-submodules` to switch between a branch with no submodules and a branch with initialized nested submodules currently causes a fatal error: $ git checkout --recurse-submodules branch-with-nested-submodules fatal: exec '--super-prefix=submodule/nested/': cd to 'nested' failed: No such file or directory error: Submodule 'nested' could not be updated. error: Submodule 'submodule/nested' cannot checkout new HEAD. error: Submodule 'submodule' could not be updated. M submodule Switched to branch 'branch-with-nested-submodules' The checkout succeeds but the worktree and index of the first level submodule are left empty: $ cd submodule $ git -c status.submoduleSummary=1 status HEAD detached at b3ce885 Changes to be committed: (use "git restore --staged <file>..." to unstage) deleted: .gitmodules deleted: first.t deleted: nested fatal: not a git repository: 'nested/.git' Submodule changes to be committed: * nested 1e96f59...0000000: $ git ls-files -s $ # empty $ ls -A .git The reason for the fatal error during the checkout is that a child git process tries to cd into the yet unexisting nested submodule directory. The sequence is the following: 1. The main git process (the one running in the superproject) eventually reaches write_entry() in entry.c, which creates the first level submodule directory and then calls submodule_move_head() in submodule.c, which spawns `git read-tree` in the submodule directory. 2. The first child git process (the one in the submodule of the superproject) eventually calls check_submodule_move_head() at unpack_trees.c:2021, which calls submodule_move_head in dry-run mode, which spawns `git read-tree` in the nested submodule directory. 3. The second child git process tries to chdir() in the yet unexisting nested submodule directory in start_command() at run-command.c:829 and dies before exec'ing. The reason why check_submodule_move_head() is reached in the first child and not in the main process is that it is inside an if(submodule_from_ce()) construct, and submodule_from_ce() returns a valid struct submodule pointer, whereas it returns a null pointer in the main git process. The reason why submodule_from_ce() returns a null pointer in the main git process is because the call to cache_lookup_path() in config_from() (called from submodule_from_path() in submodule_from_ce()) returns a null pointer since the hashmap "for_path" in the submodule_cache of the_repository is not yet populated. It is not populated because both repo_get_oid(repo, GITMODULES_INDEX, &oid) and repo_get_oid(repo, GITMODULES_HEAD, &oid) in config_from_gitmodules() at submodule-config.c:639-640 return -1, as at this stage of the operation, neither the HEAD of the superproject nor its index contain any .gitmodules file. In contrast, in the first child the hashmap is populated because repo_get_oid(repo, GITMODULES_HEAD, &oid) returns 0 as the HEAD of the first level submodule, i.e. .git/modules/submodule/HEAD, points to a commit where .gitmodules is present and records 'nested' as a submodule. Fix this bug by checking that the submodule directory exists before calling check_submodule_move_head() in merged_entry() in the `if(!old)` branch, i.e. if going from a commit with no submodule to a commit with a submodule present. Also protect the other call to check_submodule_move_head() in merged_entry() the same way as it is safer, even though the `else if (!(old->ce_flags & CE_CONFLICTED))` branch of the code is not at play in the present bug. The other calls to check_submodule_move_head() in other functions in unpack_trees.c are all already protected by calls to lstat() somewhere in the program flow so we don't need additional protection for them. All commands in the unpack_trees machinery are affected, i.e. checkout, reset and read-tree when called with the --recurse-submodules flag. This bug was first reported in [1]. [1] https://lore.kernel.org/git/7437BB59-4605-48EC-B05E-E2BDB2D9DABC@gmail.com/ Reported-by: Philippe Blain <levraiphilippeblain@gmail.com> Reported-by: Damien Robert <damien.olivier.robert@gmail.com> Signed-off-by: Philippe Blain <levraiphilippeblain@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-17 05:53:05 +01:00
# - Switching from no submodule to nested submodules
# - Switching from nested submodules to no submodule
# Internal function; use test_submodule_switch_recursing_with_args() or
# test_submodule_forced_switch_recursing_with_args() instead.
test_submodule_recursing_with_args_common () {
command="$1 --recurse-submodules"
######################### Appearing submodule #########################
# Switching to a commit letting a submodule appear checks it out ...
test_expect_success "$command: added submodule is checked out" '
prolog &&
reset_work_tree_to_interested no_submodule &&
(
cd submodule_update &&
git branch -t add_sub1 origin/add_sub1 &&
$command add_sub1 &&
test_superproject_content origin/add_sub1 &&
test_submodule_content sub1 origin/add_sub1
)
'
# ... ignoring an empty existing directory.
test_expect_success "$command: added submodule is checked out in empty dir" '
prolog &&
reset_work_tree_to_interested no_submodule &&
(
cd submodule_update &&
mkdir sub1 &&
git branch -t add_sub1 origin/add_sub1 &&
$command add_sub1 &&
test_superproject_content origin/add_sub1 &&
test_submodule_content sub1 origin/add_sub1
)
'
# Replacing a tracked file with a submodule produces a checked out submodule
test_expect_success "$command: replace tracked file with submodule checks out submodule" '
prolog &&
reset_work_tree_to_interested replace_sub1_with_file &&
(
cd submodule_update &&
git branch -t replace_file_with_sub1 origin/replace_file_with_sub1 &&
$command replace_file_with_sub1 &&
test_superproject_content origin/replace_file_with_sub1 &&
test_submodule_content sub1 origin/replace_file_with_sub1
)
'
# ... as does removing a directory with tracked files with a submodule.
test_expect_success "$command: replace directory with submodule" '
prolog &&
reset_work_tree_to_interested replace_sub1_with_directory &&
(
cd submodule_update &&
git branch -t replace_directory_with_sub1 origin/replace_directory_with_sub1 &&
$command replace_directory_with_sub1 &&
test_superproject_content origin/replace_directory_with_sub1 &&
test_submodule_content sub1 origin/replace_directory_with_sub1
)
'
unpack-trees: check for missing submodule directory in merged_entry Using `git checkout --recurse-submodules` to switch between a branch with no submodules and a branch with initialized nested submodules currently causes a fatal error: $ git checkout --recurse-submodules branch-with-nested-submodules fatal: exec '--super-prefix=submodule/nested/': cd to 'nested' failed: No such file or directory error: Submodule 'nested' could not be updated. error: Submodule 'submodule/nested' cannot checkout new HEAD. error: Submodule 'submodule' could not be updated. M submodule Switched to branch 'branch-with-nested-submodules' The checkout succeeds but the worktree and index of the first level submodule are left empty: $ cd submodule $ git -c status.submoduleSummary=1 status HEAD detached at b3ce885 Changes to be committed: (use "git restore --staged <file>..." to unstage) deleted: .gitmodules deleted: first.t deleted: nested fatal: not a git repository: 'nested/.git' Submodule changes to be committed: * nested 1e96f59...0000000: $ git ls-files -s $ # empty $ ls -A .git The reason for the fatal error during the checkout is that a child git process tries to cd into the yet unexisting nested submodule directory. The sequence is the following: 1. The main git process (the one running in the superproject) eventually reaches write_entry() in entry.c, which creates the first level submodule directory and then calls submodule_move_head() in submodule.c, which spawns `git read-tree` in the submodule directory. 2. The first child git process (the one in the submodule of the superproject) eventually calls check_submodule_move_head() at unpack_trees.c:2021, which calls submodule_move_head in dry-run mode, which spawns `git read-tree` in the nested submodule directory. 3. The second child git process tries to chdir() in the yet unexisting nested submodule directory in start_command() at run-command.c:829 and dies before exec'ing. The reason why check_submodule_move_head() is reached in the first child and not in the main process is that it is inside an if(submodule_from_ce()) construct, and submodule_from_ce() returns a valid struct submodule pointer, whereas it returns a null pointer in the main git process. The reason why submodule_from_ce() returns a null pointer in the main git process is because the call to cache_lookup_path() in config_from() (called from submodule_from_path() in submodule_from_ce()) returns a null pointer since the hashmap "for_path" in the submodule_cache of the_repository is not yet populated. It is not populated because both repo_get_oid(repo, GITMODULES_INDEX, &oid) and repo_get_oid(repo, GITMODULES_HEAD, &oid) in config_from_gitmodules() at submodule-config.c:639-640 return -1, as at this stage of the operation, neither the HEAD of the superproject nor its index contain any .gitmodules file. In contrast, in the first child the hashmap is populated because repo_get_oid(repo, GITMODULES_HEAD, &oid) returns 0 as the HEAD of the first level submodule, i.e. .git/modules/submodule/HEAD, points to a commit where .gitmodules is present and records 'nested' as a submodule. Fix this bug by checking that the submodule directory exists before calling check_submodule_move_head() in merged_entry() in the `if(!old)` branch, i.e. if going from a commit with no submodule to a commit with a submodule present. Also protect the other call to check_submodule_move_head() in merged_entry() the same way as it is safer, even though the `else if (!(old->ce_flags & CE_CONFLICTED))` branch of the code is not at play in the present bug. The other calls to check_submodule_move_head() in other functions in unpack_trees.c are all already protected by calls to lstat() somewhere in the program flow so we don't need additional protection for them. All commands in the unpack_trees machinery are affected, i.e. checkout, reset and read-tree when called with the --recurse-submodules flag. This bug was first reported in [1]. [1] https://lore.kernel.org/git/7437BB59-4605-48EC-B05E-E2BDB2D9DABC@gmail.com/ Reported-by: Philippe Blain <levraiphilippeblain@gmail.com> Reported-by: Damien Robert <damien.olivier.robert@gmail.com> Signed-off-by: Philippe Blain <levraiphilippeblain@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-17 05:53:05 +01:00
# Switching to a commit with nested submodules recursively checks them out
test_expect_success "$command: nested submodules are checked out" '
prolog &&
reset_work_tree_to_interested no_submodule &&
(
cd submodule_update &&
git branch -t modify_sub1_recursively origin/modify_sub1_recursively &&
$command modify_sub1_recursively &&
test_superproject_content origin/modify_sub1_recursively &&
test_submodule_content sub1 origin/modify_sub1_recursively &&
test_submodule_content -C sub1 sub2 origin/modify_sub1_recursively
)
'
######################## Disappearing submodule #######################
# Removing a submodule removes its work tree ...
test_expect_success "$command: removed submodule removes submodules working tree" '
prolog &&
reset_work_tree_to_interested add_sub1 &&
(
cd submodule_update &&
git branch -t remove_sub1 origin/remove_sub1 &&
$command remove_sub1 &&
test_superproject_content origin/remove_sub1 &&
submodule: unset core.worktree if no working tree is present When a submodules work tree is removed, we should unset its core.worktree setting as the worktree is no longer present. This is not just in line with the conceptual view of submodules, but it fixes an inconvenience for looking at submodules that are not checked out: git clone --recurse-submodules git://github.com/git/git && cd git && git checkout --recurse-submodules v2.13.0 git -C .git/modules/sha1collisiondetection log fatal: cannot chdir to '../../../sha1collisiondetection': \ No such file or directory With this patch applied, the final call to git log works instead of dying in its setup, as the checkout will unset the core.worktree setting such that following log will be run in a bare repository. This patch covers all commands that are in the unpack machinery, i.e. checkout, read-tree, reset. A follow up patch will address "git submodule deinit", which will also make use of the new function submodule_unset_core_worktree(), which is why we expose it in this patch. This patch was authored as 4fa4f90ccd (submodule: unset core.worktree if no working tree is present, 2018-06-12), which was reverted as part of f178c13fda (Revert "Merge branch 'sb/submodule-core-worktree'", 2018-09-07). The revert was needed as the nearby commit e98317508c (submodule: ensure core.worktree is set after update, 2018-06-18) is faulty and at the time of 7e25437d35 (Merge branch 'sb/submodule-core-worktree', 2018-07-18) we could not revert the faulty commit only, as they were depending on each other: If core.worktree is unset, we have to have ways to ensure that it is set again once the working tree reappears again. Now that 4d6d6ef1fc (Merge branch 'sb/submodule-update-in-c', 2018-09-17), specifically 74d4731da1 (submodule--helper: replace connect-gitdir-workingtree by ensure-core-worktree, 2018-08-13) is present, we already check and ensure core.worktree is set when populating a new work tree, such that we can re-introduce the commits that unset core.worktree when removing the worktree. Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-12-15 00:59:43 +01:00
! test -e sub1 &&
test_must_fail git config -f .git/modules/sub1/config core.worktree
)
'
# ... absorbing a .git directory along the way.
test_expect_success "$command: removed submodule absorbs submodules .git directory" '
prolog &&
reset_work_tree_to_interested add_sub1 &&
(
cd submodule_update &&
git branch -t remove_sub1 origin/remove_sub1 &&
replace_gitfile_with_git_dir sub1 &&
rm -rf .git/modules &&
$command remove_sub1 &&
test_superproject_content origin/remove_sub1 &&
! test -e sub1 &&
test_git_directory_exists sub1
)
'
# Replacing it with a file ...
test_expect_success "$command: replace submodule with a file" '
prolog &&
reset_work_tree_to_interested add_sub1 &&
(
cd submodule_update &&
git branch -t replace_sub1_with_file origin/replace_sub1_with_file &&
$command replace_sub1_with_file &&
test_superproject_content origin/replace_sub1_with_file &&
test -f sub1
)
'
RESULTDS=success
if test "$KNOWN_FAILURE_DIRECTORY_SUBMODULE_CONFLICTS" = 1
then
RESULTDS=failure
fi
# ... must check its local work tree for untracked files
test_expect_$RESULTDS "$command: replace submodule with a file must fail with untracked files" '
prolog &&
reset_work_tree_to_interested add_sub1 &&
(
cd submodule_update &&
git branch -t replace_sub1_with_file origin/replace_sub1_with_file &&
: >sub1/untrackedfile &&
test_must_fail $command replace_sub1_with_file &&
test_superproject_content origin/add_sub1 &&
test_submodule_content sub1 origin/add_sub1 &&
test -f sub1/untracked_file
)
'
# Switching to a commit without nested submodules removes their worktrees
test_expect_success "$command: worktrees of nested submodules are removed" '
prolog &&
reset_work_tree_to_interested add_nested_sub &&
(
cd submodule_update &&
git branch -t no_submodule origin/no_submodule &&
$command no_submodule &&
test_superproject_content origin/no_submodule &&
! test_path_is_dir sub1 &&
test_must_fail git config -f .git/modules/sub1/config core.worktree &&
test_must_fail git config -f .git/modules/sub1/modules/sub2/config core.worktree
)
'
########################## Modified submodule #########################
# Updating a submodule sha1 updates the submodule's work tree
test_expect_success "$command: modified submodule updates submodule work tree" '
prolog &&
reset_work_tree_to_interested add_sub1 &&
(
cd submodule_update &&
git branch -t modify_sub1 origin/modify_sub1 &&
$command modify_sub1 &&
test_superproject_content origin/modify_sub1 &&
test_submodule_content sub1 origin/modify_sub1
)
'
# Updating a submodule to an invalid sha1 doesn't update the
# superproject nor the submodule's work tree.
test_expect_success "$command: updating to a missing submodule commit fails" '
prolog &&
reset_work_tree_to_interested add_sub1 &&
(
cd submodule_update &&
git branch -t invalid_sub1 origin/invalid_sub1 &&
test_must_fail $command invalid_sub1 2>err &&
test_i18ngrep sub1 err &&
test_superproject_content origin/add_sub1 &&
test_submodule_content sub1 origin/add_sub1
)
'
# Updating a submodule does not touch the currently checked out branch in the submodule
test_expect_success "$command: submodule branch is not changed, detach HEAD instead" '
prolog &&
reset_work_tree_to_interested add_sub1 &&
(
cd submodule_update &&
git -C sub1 checkout -b keep_branch &&
git -C sub1 rev-parse HEAD >expect &&
git branch -t modify_sub1 origin/modify_sub1 &&
$command modify_sub1 &&
test_superproject_content origin/modify_sub1 &&
test_submodule_content sub1 origin/modify_sub1 &&
git -C sub1 rev-parse keep_branch >actual &&
test_cmp expect actual &&
test_must_fail git -C sub1 symbolic-ref HEAD
)
'
}
# Declares and invokes several tests that, in various situations, checks that
# the provided Git command, when invoked with --recurse-submodules:
# - succeeds in updating the worktree and index of a superproject to a target
# commit, or fails atomically (depending on the test situation)
# - if succeeds, the contents of submodule directories are updated
#
# Specify the Git command so that "git $GIT_COMMAND --recurse-submodules"
# works.
#
# If the command under test is known to not work with submodules in certain
# conditions, set the appropriate KNOWN_FAILURE_* variable used in the tests
# below to 1.
#
# Use as follows:
#
# test_submodule_switch_recursing_with_args "$GIT_COMMAND"
test_submodule_switch_recursing_with_args () {
cmd_args="$1"
command="git $cmd_args"
test_submodule_recursing_with_args_common "$command"
RESULTDS=success
if test "$KNOWN_FAILURE_DIRECTORY_SUBMODULE_CONFLICTS" = 1
then
RESULTDS=failure
fi
RESULTOI=success
if test "$KNOWN_FAILURE_SUBMODULE_OVERWRITE_IGNORED_UNTRACKED" = 1
then
RESULTOI=failure
fi
# Switching to a commit letting a submodule appear cannot override an
# untracked file.
test_expect_success "$command: added submodule doesn't remove untracked file with same name" '
prolog &&
reset_work_tree_to_interested no_submodule &&
(
cd submodule_update &&
git branch -t add_sub1 origin/add_sub1 &&
: >sub1 &&
test_must_fail $command add_sub1 &&
test_superproject_content origin/no_submodule &&
test_must_be_empty sub1
)
'
# ... but an ignored file is fine.
test_expect_$RESULTOI "$command: added submodule removes an untracked ignored file" '
test_when_finished "rm submodule_update/.git/info/exclude" &&
prolog &&
reset_work_tree_to_interested no_submodule &&
(
cd submodule_update &&
git branch -t add_sub1 origin/add_sub1 &&
: >sub1 &&
echo sub1 >.git/info/exclude &&
$command add_sub1 &&
test_superproject_content origin/add_sub1 &&
test_submodule_content sub1 origin/add_sub1
)
'
# Replacing a submodule with files in a directory must succeeds
# when the submodule is clean
test_expect_$RESULTDS "$command: replace submodule with a directory" '
prolog &&
reset_work_tree_to_interested add_sub1 &&
(
cd submodule_update &&
git branch -t replace_sub1_with_directory origin/replace_sub1_with_directory &&
$command replace_sub1_with_directory &&
test_superproject_content origin/replace_sub1_with_directory &&
test_submodule_content sub1 origin/replace_sub1_with_directory
)
'
# ... absorbing a .git directory.
test_expect_$RESULTDS "$command: replace submodule containing a .git directory with a directory must absorb the git dir" '
prolog &&
reset_work_tree_to_interested add_sub1 &&
(
cd submodule_update &&
git branch -t replace_sub1_with_directory origin/replace_sub1_with_directory &&
replace_gitfile_with_git_dir sub1 &&
rm -rf .git/modules &&
$command replace_sub1_with_directory &&
test_superproject_content origin/replace_sub1_with_directory &&
test_git_directory_exists sub1
)
'
# ... and ignored files are ignored
test_expect_success "$command: replace submodule with a file works ignores ignored files in submodule" '
test_when_finished "rm submodule_update/.git/modules/sub1/info/exclude" &&
prolog &&
reset_work_tree_to_interested add_sub1 &&
(
cd submodule_update &&
git branch -t replace_sub1_with_file origin/replace_sub1_with_file &&
echo ignored >.git/modules/sub1/info/exclude &&
: >sub1/ignored &&
$command replace_sub1_with_file &&
test_superproject_content origin/replace_sub1_with_file &&
test -f sub1
)
'
test_expect_success "git -c submodule.recurse=true $cmd_args: modified submodule updates submodule work tree" '
prolog &&
reset_work_tree_to_interested add_sub1 &&
(
cd submodule_update &&
git branch -t modify_sub1 origin/modify_sub1 &&
git -c submodule.recurse=true $cmd_args modify_sub1 &&
test_superproject_content origin/modify_sub1 &&
test_submodule_content sub1 origin/modify_sub1
)
'
test_expect_success "$command: modified submodule updates submodule recursively" '
prolog &&
reset_work_tree_to_interested add_nested_sub &&
(
cd submodule_update &&
git branch -t modify_sub1_recursively origin/modify_sub1_recursively &&
$command modify_sub1_recursively &&
test_superproject_content origin/modify_sub1_recursively &&
test_submodule_content sub1 origin/modify_sub1_recursively &&
test_submodule_content -C sub1 sub2 origin/modify_sub1_recursively
)
'
}
# Same as test_submodule_switch_recursing_with_args(), except that throwing
# away local changes in the superproject is allowed.
test_submodule_forced_switch_recursing_with_args () {
cmd_args="$1"
command="git $cmd_args"
test_submodule_recursing_with_args_common "$command"
RESULT=success
if test "$KNOWN_FAILURE_DIRECTORY_SUBMODULE_CONFLICTS" = 1
then
RESULT=failure
fi
# Switching to a commit letting a submodule appear does not care about
# an untracked file.
test_expect_success "$command: added submodule does remove untracked unignored file with same name when forced" '
prolog &&
reset_work_tree_to_interested no_submodule &&
(
cd submodule_update &&
git branch -t add_sub1 origin/add_sub1 &&
>sub1 &&
$command add_sub1 &&
test_superproject_content origin/add_sub1 &&
test_submodule_content sub1 origin/add_sub1
)
'
# Replacing a submodule with files in a directory ...
test_expect_success "$command: replace submodule with a directory" '
prolog &&
reset_work_tree_to_interested add_sub1 &&
(
cd submodule_update &&
git branch -t replace_sub1_with_directory origin/replace_sub1_with_directory &&
$command replace_sub1_with_directory &&
test_superproject_content origin/replace_sub1_with_directory
)
'
# ... absorbing a .git directory.
test_expect_success "$command: replace submodule containing a .git directory with a directory must fail" '
prolog &&
reset_work_tree_to_interested add_sub1 &&
(
cd submodule_update &&
git branch -t replace_sub1_with_directory origin/replace_sub1_with_directory &&
replace_gitfile_with_git_dir sub1 &&
rm -rf .git/modules/sub1 &&
$command replace_sub1_with_directory &&
test_superproject_content origin/replace_sub1_with_directory &&
test_git_directory_exists sub1
)
'
# ... even if the submodule contains ignored files
test_expect_success "$command: replace submodule with a file ignoring ignored files" '
prolog &&
reset_work_tree_to_interested add_sub1 &&
(
cd submodule_update &&
git branch -t replace_sub1_with_file origin/replace_sub1_with_file &&
: >sub1/expect &&
$command replace_sub1_with_file &&
test_superproject_content origin/replace_sub1_with_file
)
'
# Updating a submodule from an invalid sha1 updates
test_expect_success "$command: modified submodule does update submodule work tree from invalid commit" '
prolog &&
reset_work_tree_to_interested invalid_sub1 &&
(
cd submodule_update &&
git branch -t valid_sub1 origin/valid_sub1 &&
$command valid_sub1 &&
test_superproject_content origin/valid_sub1 &&
test_submodule_content sub1 origin/valid_sub1
)
'
# Old versions of Git were buggy writing the .git link file
# (e.g. before f8eaa0ba98b and then moving the superproject repo
# whose submodules contained absolute paths)
test_expect_success "$command: updating submodules fixes .git links" '
prolog &&
reset_work_tree_to_interested add_sub1 &&
(
cd submodule_update &&
git branch -t modify_sub1 origin/modify_sub1 &&
echo "gitdir: bogus/path" >sub1/.git &&
$command modify_sub1 &&
test_superproject_content origin/modify_sub1 &&
test_submodule_content sub1 origin/modify_sub1
)
'
test_expect_success "$command: changed submodule worktree is reset" '
prolog &&
reset_work_tree_to_interested add_sub1 &&
(
cd submodule_update &&
rm sub1/file1 &&
: >sub1/new_file &&
git -C sub1 add new_file &&
$command HEAD &&
test_path_is_file sub1/file1 &&
test_path_is_missing sub1/new_file
)
'
}