git/t/t7400-submodule-basic.sh

1486 lines
41 KiB
Bash
Raw Normal View History

#!/bin/sh
#
# Copyright (c) 2007 Lars Hjemli
#
test_description='Basic porcelain support for submodules
This test tries to verify basic sanity of the init, update and status
subcommands of git submodule.
'
GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=main
tests: mark tests relying on the current default for `init.defaultBranch` In addition to the manual adjustment to let the `linux-gcc` CI job run the test suite with `master` and then with `main`, this patch makes sure that GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME is set in all test scripts that currently rely on the initial branch name being `master by default. To determine which test scripts to mark up, the first step was to force-set the default branch name to `master` in - all test scripts that contain the keyword `master`, - t4211, which expects `t/t4211/history.export` with a hard-coded ref to initialize the default branch, - t5560 because it sources `t/t556x_common` which uses `master`, - t8002 and t8012 because both source `t/annotate-tests.sh` which also uses `master`) This trick was performed by this command: $ sed -i '/^ *\. \.\/\(test-lib\|lib-\(bash\|cvs\|git-svn\)\|gitweb-lib\)\.sh$/i\ GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=master\ export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME\ ' $(git grep -l master t/t[0-9]*.sh) \ t/t4211*.sh t/t5560*.sh t/t8002*.sh t/t8012*.sh After that, careful, manual inspection revealed that some of the test scripts containing the needle `master` do not actually rely on a specific default branch name: either they mention `master` only in a comment, or they initialize that branch specificially, or they do not actually refer to the current default branch. Therefore, the aforementioned modification was undone in those test scripts thusly: $ git checkout HEAD -- \ t/t0027-auto-crlf.sh t/t0060-path-utils.sh \ t/t1011-read-tree-sparse-checkout.sh \ t/t1305-config-include.sh t/t1309-early-config.sh \ t/t1402-check-ref-format.sh t/t1450-fsck.sh \ t/t2024-checkout-dwim.sh \ t/t2106-update-index-assume-unchanged.sh \ t/t3040-subprojects-basic.sh t/t3301-notes.sh \ t/t3308-notes-merge.sh t/t3423-rebase-reword.sh \ t/t3436-rebase-more-options.sh \ t/t4015-diff-whitespace.sh t/t4257-am-interactive.sh \ t/t5323-pack-redundant.sh t/t5401-update-hooks.sh \ t/t5511-refspec.sh t/t5526-fetch-submodules.sh \ t/t5529-push-errors.sh t/t5530-upload-pack-error.sh \ t/t5548-push-porcelain.sh \ t/t5552-skipping-fetch-negotiator.sh \ t/t5572-pull-submodule.sh t/t5608-clone-2gb.sh \ t/t5614-clone-submodules-shallow.sh \ t/t7508-status.sh t/t7606-merge-custom.sh \ t/t9302-fast-import-unpack-limit.sh We excluded one set of test scripts in these commands, though: the range of `git p4` tests. The reason? `git p4` stores the (foreign) remote branch in the branch called `p4/master`, which is obviously not the default branch. Manual analysis revealed that only five of these tests actually require a specific default branch name to pass; They were modified thusly: $ sed -i '/^ *\. \.\/lib-git-p4\.sh$/i\ GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=master\ export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME\ ' t/t980[0167]*.sh t/t9811*.sh Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-18 23:44:19 +00:00
export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME
. ./test-lib.sh
test_expect_success 'setup - enable local submodules' '
git config --global protocol.file.allow always
'
test_expect_success 'submodule usage: -h' '
git submodule -h >out 2>err &&
grep "^usage: git submodule" out &&
test_must_be_empty err
'
test_expect_success 'submodule usage: --recursive' '
test_expect_code 1 git submodule --recursive >out 2>err &&
grep "^usage: git submodule" err &&
test_must_be_empty out
'
test_expect_success 'submodule usage: status --' '
test_expect_code 1 git submodule -- &&
test_expect_code 1 git submodule --end-of-options
'
for opt in '--quiet' '--cached'
do
test_expect_success "submodule usage: status $opt" '
git submodule $opt &&
git submodule status $opt &&
git submodule $opt status
'
done
test_expect_success 'submodule deinit works on empty repository' '
git submodule deinit --all
'
test_expect_success 'setup - initial commit' '
>t &&
git add t &&
git commit -m "initial commit" &&
git branch initial
'
test_expect_success 'submodule init aborts on missing .gitmodules file' '
test_when_finished "git update-index --remove sub" &&
git update-index --add --cacheinfo 160000,$(git rev-parse HEAD),sub &&
# missing the .gitmodules file here
test_must_fail git submodule init 2>actual &&
test_grep "No url found for submodule path" actual
'
test_expect_success 'submodule update aborts on missing .gitmodules file' '
test_when_finished "git update-index --remove sub" &&
git update-index --add --cacheinfo 160000,$(git rev-parse HEAD),sub &&
# missing the .gitmodules file here
git submodule update sub 2>actual &&
test_grep "Submodule path .sub. not initialized" actual
'
test_expect_success 'submodule update aborts on missing gitmodules url' '
test_when_finished "git update-index --remove sub" &&
git update-index --add --cacheinfo 160000,$(git rev-parse HEAD),sub &&
test_when_finished "rm -f .gitmodules" &&
git config -f .gitmodules submodule.s.path sub &&
test_must_fail git submodule init
'
test_expect_success 'add aborts on repository with no commits' '
cat >expect <<-\EOF &&
fatal: '"'repo-no-commits'"' does not have a commit checked out
EOF
git init repo-no-commits &&
test_must_fail git submodule add ../a ./repo-no-commits 2>actual &&
test_cmp expect actual
'
test_expect_success 'status should ignore inner git repo when not added' '
rm -fr inner &&
mkdir inner &&
(
cd inner &&
git init &&
>t &&
git add t &&
git commit -m "initial"
) &&
test_must_fail git submodule status inner 2>output.err &&
rm -fr inner &&
test_grep "^error: .*did not match any file(s) known to git" output.err
'
test_expect_success 'setup - repository in init subdirectory' '
mkdir init &&
(
cd init &&
git init &&
echo a >a &&
git add a &&
git commit -m "submodule commit 1" &&
git tag -a -m "rev-1" rev-1
)
'
test_expect_success 'setup - commit with gitlink' '
echo a >a &&
echo z >z &&
git add a init z &&
git commit -m "super commit 1"
'
test_expect_success 'setup - hide init subdirectory' '
mv init .subrepo
'
test_expect_success 'setup - repository to add submodules to' '
git submodule: add submodules with git add -f <path> Change `git submodule add' to add the new submodule <path> with `git add --force'. I keep my /etc in .git with a .gitignore that contains just "*". I.e. `git status' will ignore everything that isn't in the tree already. When I do: git submodule add <url> hlagh git-submodule will get as far as checking out the remote repository into hlagh, but it'll die right afterwards when it fails to add the new path: The following paths are ignored by one of your .gitignore files: hlagh Use -f if you really want to add them. fatal: no files added Failed to add submodule 'hlagh' Currently there's no way to add a submodule in this situation other than to remove the ignored path from the .gitignore while I'm at it. That's silly, when you run `git submodule add' you're explicitly saying that you want to add something *new* to the repository. Instead it should just add the path with `git add --force'. Initially I implemented this by adding new -f and --force options to `git submodule add'. But if the --force option isn't supplied it'll get as far as cloning `hlagh', but won't add it. So the first thing the user has to do is to remove `hlagh' and then try again with the --force option. That sucks, it should just add the path to begin with. I can't think of any usecase where you've gone through the trouble of typing out `git submodule add ..', but wish to be overriden by a `gitignore'. The submodule semantics should be more like `git init', not `git add'. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-07-05 17:33:03 +00:00
git init addtest &&
git init addtest-ignore
'
# The 'submodule add' tests need some repository to add as a submodule.
# The trash directory is a good one as any. We need to canonicalize
# the name, though, as some tests compare it to the absolute path git
# generates, which will expand symbolic links.
submodurl=$(pwd -P)
listbranches() {
git for-each-ref --format='%(refname)' 'refs/heads/*'
}
inspect() {
dir=$1 &&
dotdot="${2:-..}" &&
(
cd "$dir" &&
listbranches >"$dotdot/heads" &&
{ git symbolic-ref HEAD || :; } >"$dotdot/head" &&
git rev-parse HEAD >"$dotdot/head-sha1" &&
git update-index --refresh &&
git diff-files --exit-code &&
git clean -n -d -x >"$dotdot/untracked"
)
}
test_expect_success 'submodule add' '
echo "refs/heads/main" >expect &&
(
cd addtest &&
git submodule add -q "$submodurl" submod >actual &&
test_must_be_empty actual &&
2012-03-04 21:14:30 +00:00
echo "gitdir: ../.git/modules/submod" >expect &&
test_cmp expect submod/.git &&
(
cd submod &&
git config core.worktree >actual &&
echo "../../../submod" >expect &&
test_cmp expect actual &&
rm -f actual expect
) &&
git submodule init
) &&
rm -f heads head untracked &&
inspect addtest/submod ../.. &&
test_cmp expect heads &&
test_cmp expect head &&
tests: use 'test_must_be_empty' instead of 'test_cmp <empty> <out>' Using 'test_must_be_empty' is shorter and more idiomatic than >empty && test_cmp empty out as it saves the creation of an empty file. Furthermore, sometimes the expected empty file doesn't have such a descriptive name like 'empty', and its creation is far away from the place where it's finally used for comparison (e.g. in 't7600-merge.sh', where two expected empty files are created in the 'setup' test, but are used only about 500 lines later). These cases were found by instrumenting 'test_cmp' to error out the test script when it's used to compare empty files, and then converted manually. Note that even after this patch there still remain a lot of cases where we use 'test_cmp' to check empty files: - Sometimes the expected output is not hard-coded in the test, but 'test_cmp' is used to ensure that two similar git commands produce the same output, and that output happens to be empty, e.g. the test 'submodule update --merge - ignores --merge for new submodules' in 't7406-submodule-update.sh'. - Repetitive common tasks, including preparing the expected results and running 'test_cmp', are often extracted into a helper function, and some of this helper's callsites expect no output. - For the same reason as above, the whole 'test_expect_success' block is within a helper function, e.g. in 't3070-wildmatch.sh'. - Or 'test_cmp' is invoked in a loop, e.g. the test 'cvs update (-p)' in 't9400-git-cvsserver-server.sh'. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-19 21:57:25 +00:00
test_must_be_empty untracked
'
test_expect_success !WINDOWS 'submodule add (absolute path)' '
test_when_finished "git reset --hard" &&
git submodule add "$submodurl" "$submodurl/add-abs"
'
test_expect_success 'setup parent and one repository' '
test_create_repo parent &&
test_commit -C parent one
'
test_expect_success 'redirected submodule add does not show progress' '
git -C addtest submodule add "file://$submodurl/parent" submod-redirected \
2>err &&
! grep % err &&
test_grep ! "Checking connectivity" err
'
test_expect_success 'redirected submodule add --progress does show progress' '
git -C addtest submodule add --progress "file://$submodurl/parent" \
submod-redirected-progress 2>err && \
grep % err
'
test_expect_success 'submodule add to .gitignored path fails' '
git submodule: add submodules with git add -f <path> Change `git submodule add' to add the new submodule <path> with `git add --force'. I keep my /etc in .git with a .gitignore that contains just "*". I.e. `git status' will ignore everything that isn't in the tree already. When I do: git submodule add <url> hlagh git-submodule will get as far as checking out the remote repository into hlagh, but it'll die right afterwards when it fails to add the new path: The following paths are ignored by one of your .gitignore files: hlagh Use -f if you really want to add them. fatal: no files added Failed to add submodule 'hlagh' Currently there's no way to add a submodule in this situation other than to remove the ignored path from the .gitignore while I'm at it. That's silly, when you run `git submodule add' you're explicitly saying that you want to add something *new* to the repository. Instead it should just add the path with `git add --force'. Initially I implemented this by adding new -f and --force options to `git submodule add'. But if the --force option isn't supplied it'll get as far as cloning `hlagh', but won't add it. So the first thing the user has to do is to remove `hlagh' and then try again with the --force option. That sucks, it should just add the path to begin with. I can't think of any usecase where you've gone through the trouble of typing out `git submodule add ..', but wish to be overriden by a `gitignore'. The submodule semantics should be more like `git init', not `git add'. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-07-05 17:33:03 +00:00
(
cd addtest-ignore &&
cat <<-\EOF >expect &&
submodule add: show 'add --dry-run' stderr when aborting Unless --force is specified, 'submodule add' checks if the destination path is ignored by calling 'git add --dry-run --ignore-missing', and, if that call fails, aborts with a custom "path is ignored" message (a slight variant of what 'git add' shows). Aborting early rather than letting the downstream 'git add' call fail is done so that the command exits before cloning into the destination path. However, in rare cases where the dry-run call fails for a reason other than the path being ignored---for example, due to a preexisting index.lock file---displaying the "ignored path" error message hides the real source of the failure. Instead of displaying the tailored "ignored path" message, let's report the standard error from the dry run to give the caller more accurate information about failures that are not due to an ignored path. For the ignored path case, this leads to the following change in the error message: The following [-path is-]{+paths are+} ignored by one of your .gitignore files: <destination path> Use -f if you really want to add [-it.-]{+them.+} The new phrasing is a bit awkward, because 'submodule add' is only dealing with one destination path. Alternatively, we could continue to use the tailored message when the exit code is 1 (the expected status for a failure due to an ignored path) and relay the standard error for all other non-zero exits. That, however, risks hiding the message of unrelated failures that share an exit code of 1, so it doesn't seem worth doing just to avoid a clunkier, but still clear, error message. Signed-off-by: Kyle Meyer <kyle@kyleam.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-01-08 00:31:21 +00:00
The following paths are ignored by one of your .gitignore files:
submod
hint: Use -f if you really want to add them.
hint: Disable this message with "git config advice.addIgnoredFile false"
EOF
git submodule: add submodules with git add -f <path> Change `git submodule add' to add the new submodule <path> with `git add --force'. I keep my /etc in .git with a .gitignore that contains just "*". I.e. `git status' will ignore everything that isn't in the tree already. When I do: git submodule add <url> hlagh git-submodule will get as far as checking out the remote repository into hlagh, but it'll die right afterwards when it fails to add the new path: The following paths are ignored by one of your .gitignore files: hlagh Use -f if you really want to add them. fatal: no files added Failed to add submodule 'hlagh' Currently there's no way to add a submodule in this situation other than to remove the ignored path from the .gitignore while I'm at it. That's silly, when you run `git submodule add' you're explicitly saying that you want to add something *new* to the repository. Instead it should just add the path with `git add --force'. Initially I implemented this by adding new -f and --force options to `git submodule add'. But if the --force option isn't supplied it'll get as far as cloning `hlagh', but won't add it. So the first thing the user has to do is to remove `hlagh' and then try again with the --force option. That sucks, it should just add the path to begin with. I can't think of any usecase where you've gone through the trouble of typing out `git submodule add ..', but wish to be overriden by a `gitignore'. The submodule semantics should be more like `git init', not `git add'. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-07-05 17:33:03 +00:00
# Does not use test_commit due to the ignore
echo "*" > .gitignore &&
git add --force .gitignore &&
git commit -m"Ignore everything" &&
! git submodule add "$submodurl" submod >actual 2>&1 &&
test_cmp expect actual
)
'
git submodule: add submodules with git add -f <path> Change `git submodule add' to add the new submodule <path> with `git add --force'. I keep my /etc in .git with a .gitignore that contains just "*". I.e. `git status' will ignore everything that isn't in the tree already. When I do: git submodule add <url> hlagh git-submodule will get as far as checking out the remote repository into hlagh, but it'll die right afterwards when it fails to add the new path: The following paths are ignored by one of your .gitignore files: hlagh Use -f if you really want to add them. fatal: no files added Failed to add submodule 'hlagh' Currently there's no way to add a submodule in this situation other than to remove the ignored path from the .gitignore while I'm at it. That's silly, when you run `git submodule add' you're explicitly saying that you want to add something *new* to the repository. Instead it should just add the path with `git add --force'. Initially I implemented this by adding new -f and --force options to `git submodule add'. But if the --force option isn't supplied it'll get as far as cloning `hlagh', but won't add it. So the first thing the user has to do is to remove `hlagh' and then try again with the --force option. That sucks, it should just add the path to begin with. I can't think of any usecase where you've gone through the trouble of typing out `git submodule add ..', but wish to be overriden by a `gitignore'. The submodule semantics should be more like `git init', not `git add'. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-07-05 17:33:03 +00:00
test_expect_success 'submodule add to .gitignored path with --force' '
(
cd addtest-ignore &&
git submodule add --force "$submodurl" submod
)
git submodule: add submodules with git add -f <path> Change `git submodule add' to add the new submodule <path> with `git add --force'. I keep my /etc in .git with a .gitignore that contains just "*". I.e. `git status' will ignore everything that isn't in the tree already. When I do: git submodule add <url> hlagh git-submodule will get as far as checking out the remote repository into hlagh, but it'll die right afterwards when it fails to add the new path: The following paths are ignored by one of your .gitignore files: hlagh Use -f if you really want to add them. fatal: no files added Failed to add submodule 'hlagh' Currently there's no way to add a submodule in this situation other than to remove the ignored path from the .gitignore while I'm at it. That's silly, when you run `git submodule add' you're explicitly saying that you want to add something *new* to the repository. Instead it should just add the path with `git add --force'. Initially I implemented this by adding new -f and --force options to `git submodule add'. But if the --force option isn't supplied it'll get as far as cloning `hlagh', but won't add it. So the first thing the user has to do is to remove `hlagh' and then try again with the --force option. That sucks, it should just add the path to begin with. I can't think of any usecase where you've gone through the trouble of typing out `git submodule add ..', but wish to be overriden by a `gitignore'. The submodule semantics should be more like `git init', not `git add'. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-07-05 17:33:03 +00:00
'
test_expect_success 'submodule add to path with tracked content fails' '
(
cd addtest &&
echo "fatal: '\''dir-tracked'\'' already exists in the index" >expect &&
mkdir dir-tracked &&
test_commit foo dir-tracked/bar &&
test_must_fail git submodule add "$submodurl" dir-tracked >actual 2>&1 &&
test_cmp expect actual
)
'
test_expect_success 'submodule add to reconfigure existing submodule with --force' '
(
cd addtest-ignore &&
bogus_url="$(pwd)/bogus-url" &&
git submodule add --force "$bogus_url" submod &&
git submodule add --force -b initial "$submodurl" submod-branch &&
test "$bogus_url" = "$(git config -f .gitmodules submodule.submod.url)" &&
test "$bogus_url" = "$(git config submodule.submod.url)" &&
# Restore the url
git submodule add --force "$submodurl" submod &&
test "$submodurl" = "$(git config -f .gitmodules submodule.submod.url)" &&
test "$submodurl" = "$(git config submodule.submod.url)"
)
'
submodule add: show 'add --dry-run' stderr when aborting Unless --force is specified, 'submodule add' checks if the destination path is ignored by calling 'git add --dry-run --ignore-missing', and, if that call fails, aborts with a custom "path is ignored" message (a slight variant of what 'git add' shows). Aborting early rather than letting the downstream 'git add' call fail is done so that the command exits before cloning into the destination path. However, in rare cases where the dry-run call fails for a reason other than the path being ignored---for example, due to a preexisting index.lock file---displaying the "ignored path" error message hides the real source of the failure. Instead of displaying the tailored "ignored path" message, let's report the standard error from the dry run to give the caller more accurate information about failures that are not due to an ignored path. For the ignored path case, this leads to the following change in the error message: The following [-path is-]{+paths are+} ignored by one of your .gitignore files: <destination path> Use -f if you really want to add [-it.-]{+them.+} The new phrasing is a bit awkward, because 'submodule add' is only dealing with one destination path. Alternatively, we could continue to use the tailored message when the exit code is 1 (the expected status for a failure due to an ignored path) and relay the standard error for all other non-zero exits. That, however, risks hiding the message of unrelated failures that share an exit code of 1, so it doesn't seem worth doing just to avoid a clunkier, but still clear, error message. Signed-off-by: Kyle Meyer <kyle@kyleam.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-01-08 00:31:21 +00:00
test_expect_success 'submodule add relays add --dry-run stderr' '
test_when_finished "rm -rf addtest/.git/index.lock" &&
(
cd addtest &&
: >.git/index.lock &&
! git submodule add "$submodurl" sub-while-locked 2>output.err &&
test_grep "^fatal: .*index\.lock" output.err &&
submodule add: show 'add --dry-run' stderr when aborting Unless --force is specified, 'submodule add' checks if the destination path is ignored by calling 'git add --dry-run --ignore-missing', and, if that call fails, aborts with a custom "path is ignored" message (a slight variant of what 'git add' shows). Aborting early rather than letting the downstream 'git add' call fail is done so that the command exits before cloning into the destination path. However, in rare cases where the dry-run call fails for a reason other than the path being ignored---for example, due to a preexisting index.lock file---displaying the "ignored path" error message hides the real source of the failure. Instead of displaying the tailored "ignored path" message, let's report the standard error from the dry run to give the caller more accurate information about failures that are not due to an ignored path. For the ignored path case, this leads to the following change in the error message: The following [-path is-]{+paths are+} ignored by one of your .gitignore files: <destination path> Use -f if you really want to add [-it.-]{+them.+} The new phrasing is a bit awkward, because 'submodule add' is only dealing with one destination path. Alternatively, we could continue to use the tailored message when the exit code is 1 (the expected status for a failure due to an ignored path) and relay the standard error for all other non-zero exits. That, however, risks hiding the message of unrelated failures that share an exit code of 1, so it doesn't seem worth doing just to avoid a clunkier, but still clear, error message. Signed-off-by: Kyle Meyer <kyle@kyleam.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-01-08 00:31:21 +00:00
test_path_is_missing sub-while-locked
)
'
test_expect_success 'submodule add --branch' '
echo "refs/heads/initial" >expect-head &&
cat <<-\EOF >expect-heads &&
refs/heads/initial
refs/heads/main
EOF
(
cd addtest &&
git submodule add -b initial "$submodurl" submod-branch &&
test "initial" = "$(git config -f .gitmodules submodule.submod-branch.branch)" &&
git submodule init
) &&
rm -f heads head untracked &&
inspect addtest/submod-branch ../.. &&
test_cmp expect-heads heads &&
test_cmp expect-head head &&
tests: use 'test_must_be_empty' instead of 'test_cmp <empty> <out>' Using 'test_must_be_empty' is shorter and more idiomatic than >empty && test_cmp empty out as it saves the creation of an empty file. Furthermore, sometimes the expected empty file doesn't have such a descriptive name like 'empty', and its creation is far away from the place where it's finally used for comparison (e.g. in 't7600-merge.sh', where two expected empty files are created in the 'setup' test, but are used only about 500 lines later). These cases were found by instrumenting 'test_cmp' to error out the test script when it's used to compare empty files, and then converted manually. Note that even after this patch there still remain a lot of cases where we use 'test_cmp' to check empty files: - Sometimes the expected output is not hard-coded in the test, but 'test_cmp' is used to ensure that two similar git commands produce the same output, and that output happens to be empty, e.g. the test 'submodule update --merge - ignores --merge for new submodules' in 't7406-submodule-update.sh'. - Repetitive common tasks, including preparing the expected results and running 'test_cmp', are often extracted into a helper function, and some of this helper's callsites expect no output. - For the same reason as above, the whole 'test_expect_success' block is within a helper function, e.g. in 't3070-wildmatch.sh'. - Or 'test_cmp' is invoked in a loop, e.g. the test 'cvs update (-p)' in 't9400-git-cvsserver-server.sh'. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-19 21:57:25 +00:00
test_must_be_empty untracked
'
test_expect_success 'submodule add with ./ in path' '
echo "refs/heads/main" >expect &&
(
cd addtest &&
git submodule add "$submodurl" ././dotsubmod/./frotz/./ &&
git submodule init
) &&
rm -f heads head untracked &&
inspect addtest/dotsubmod/frotz ../../.. &&
test_cmp expect heads &&
test_cmp expect head &&
tests: use 'test_must_be_empty' instead of 'test_cmp <empty> <out>' Using 'test_must_be_empty' is shorter and more idiomatic than >empty && test_cmp empty out as it saves the creation of an empty file. Furthermore, sometimes the expected empty file doesn't have such a descriptive name like 'empty', and its creation is far away from the place where it's finally used for comparison (e.g. in 't7600-merge.sh', where two expected empty files are created in the 'setup' test, but are used only about 500 lines later). These cases were found by instrumenting 'test_cmp' to error out the test script when it's used to compare empty files, and then converted manually. Note that even after this patch there still remain a lot of cases where we use 'test_cmp' to check empty files: - Sometimes the expected output is not hard-coded in the test, but 'test_cmp' is used to ensure that two similar git commands produce the same output, and that output happens to be empty, e.g. the test 'submodule update --merge - ignores --merge for new submodules' in 't7406-submodule-update.sh'. - Repetitive common tasks, including preparing the expected results and running 'test_cmp', are often extracted into a helper function, and some of this helper's callsites expect no output. - For the same reason as above, the whole 'test_expect_success' block is within a helper function, e.g. in 't3070-wildmatch.sh'. - Or 'test_cmp' is invoked in a loop, e.g. the test 'cvs update (-p)' in 't9400-git-cvsserver-server.sh'. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-19 21:57:25 +00:00
test_must_be_empty untracked
'
test_expect_success 'submodule add with /././ in path' '
echo "refs/heads/main" >expect &&
(
cd addtest &&
git submodule add "$submodurl" dotslashdotsubmod/././frotz/./ &&
git submodule init
) &&
rm -f heads head untracked &&
inspect addtest/dotslashdotsubmod/frotz ../../.. &&
test_cmp expect heads &&
test_cmp expect head &&
tests: use 'test_must_be_empty' instead of 'test_cmp <empty> <out>' Using 'test_must_be_empty' is shorter and more idiomatic than >empty && test_cmp empty out as it saves the creation of an empty file. Furthermore, sometimes the expected empty file doesn't have such a descriptive name like 'empty', and its creation is far away from the place where it's finally used for comparison (e.g. in 't7600-merge.sh', where two expected empty files are created in the 'setup' test, but are used only about 500 lines later). These cases were found by instrumenting 'test_cmp' to error out the test script when it's used to compare empty files, and then converted manually. Note that even after this patch there still remain a lot of cases where we use 'test_cmp' to check empty files: - Sometimes the expected output is not hard-coded in the test, but 'test_cmp' is used to ensure that two similar git commands produce the same output, and that output happens to be empty, e.g. the test 'submodule update --merge - ignores --merge for new submodules' in 't7406-submodule-update.sh'. - Repetitive common tasks, including preparing the expected results and running 'test_cmp', are often extracted into a helper function, and some of this helper's callsites expect no output. - For the same reason as above, the whole 'test_expect_success' block is within a helper function, e.g. in 't3070-wildmatch.sh'. - Or 'test_cmp' is invoked in a loop, e.g. the test 'cvs update (-p)' in 't9400-git-cvsserver-server.sh'. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-19 21:57:25 +00:00
test_must_be_empty untracked
'
test_expect_success 'submodule add with // in path' '
echo "refs/heads/main" >expect &&
(
cd addtest &&
git submodule add "$submodurl" slashslashsubmod///frotz// &&
git submodule init
) &&
rm -f heads head untracked &&
inspect addtest/slashslashsubmod/frotz ../../.. &&
test_cmp expect heads &&
test_cmp expect head &&
tests: use 'test_must_be_empty' instead of 'test_cmp <empty> <out>' Using 'test_must_be_empty' is shorter and more idiomatic than >empty && test_cmp empty out as it saves the creation of an empty file. Furthermore, sometimes the expected empty file doesn't have such a descriptive name like 'empty', and its creation is far away from the place where it's finally used for comparison (e.g. in 't7600-merge.sh', where two expected empty files are created in the 'setup' test, but are used only about 500 lines later). These cases were found by instrumenting 'test_cmp' to error out the test script when it's used to compare empty files, and then converted manually. Note that even after this patch there still remain a lot of cases where we use 'test_cmp' to check empty files: - Sometimes the expected output is not hard-coded in the test, but 'test_cmp' is used to ensure that two similar git commands produce the same output, and that output happens to be empty, e.g. the test 'submodule update --merge - ignores --merge for new submodules' in 't7406-submodule-update.sh'. - Repetitive common tasks, including preparing the expected results and running 'test_cmp', are often extracted into a helper function, and some of this helper's callsites expect no output. - For the same reason as above, the whole 'test_expect_success' block is within a helper function, e.g. in 't3070-wildmatch.sh'. - Or 'test_cmp' is invoked in a loop, e.g. the test 'cvs update (-p)' in 't9400-git-cvsserver-server.sh'. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-19 21:57:25 +00:00
test_must_be_empty untracked
'
test_expect_success 'submodule add with /.. in path' '
echo "refs/heads/main" >expect &&
(
cd addtest &&
git submodule add "$submodurl" dotdotsubmod/../realsubmod/frotz/.. &&
git submodule init
) &&
rm -f heads head untracked &&
inspect addtest/realsubmod ../.. &&
test_cmp expect heads &&
test_cmp expect head &&
tests: use 'test_must_be_empty' instead of 'test_cmp <empty> <out>' Using 'test_must_be_empty' is shorter and more idiomatic than >empty && test_cmp empty out as it saves the creation of an empty file. Furthermore, sometimes the expected empty file doesn't have such a descriptive name like 'empty', and its creation is far away from the place where it's finally used for comparison (e.g. in 't7600-merge.sh', where two expected empty files are created in the 'setup' test, but are used only about 500 lines later). These cases were found by instrumenting 'test_cmp' to error out the test script when it's used to compare empty files, and then converted manually. Note that even after this patch there still remain a lot of cases where we use 'test_cmp' to check empty files: - Sometimes the expected output is not hard-coded in the test, but 'test_cmp' is used to ensure that two similar git commands produce the same output, and that output happens to be empty, e.g. the test 'submodule update --merge - ignores --merge for new submodules' in 't7406-submodule-update.sh'. - Repetitive common tasks, including preparing the expected results and running 'test_cmp', are often extracted into a helper function, and some of this helper's callsites expect no output. - For the same reason as above, the whole 'test_expect_success' block is within a helper function, e.g. in 't3070-wildmatch.sh'. - Or 'test_cmp' is invoked in a loop, e.g. the test 'cvs update (-p)' in 't9400-git-cvsserver-server.sh'. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-19 21:57:25 +00:00
test_must_be_empty untracked
'
test_expect_success 'submodule add with ./, /.. and // in path' '
echo "refs/heads/main" >expect &&
(
cd addtest &&
git submodule add "$submodurl" dot/dotslashsubmod/./../..////realsubmod2/a/b/c/d/../../../../frotz//.. &&
git submodule init
) &&
rm -f heads head untracked &&
inspect addtest/realsubmod2 ../.. &&
test_cmp expect heads &&
test_cmp expect head &&
tests: use 'test_must_be_empty' instead of 'test_cmp <empty> <out>' Using 'test_must_be_empty' is shorter and more idiomatic than >empty && test_cmp empty out as it saves the creation of an empty file. Furthermore, sometimes the expected empty file doesn't have such a descriptive name like 'empty', and its creation is far away from the place where it's finally used for comparison (e.g. in 't7600-merge.sh', where two expected empty files are created in the 'setup' test, but are used only about 500 lines later). These cases were found by instrumenting 'test_cmp' to error out the test script when it's used to compare empty files, and then converted manually. Note that even after this patch there still remain a lot of cases where we use 'test_cmp' to check empty files: - Sometimes the expected output is not hard-coded in the test, but 'test_cmp' is used to ensure that two similar git commands produce the same output, and that output happens to be empty, e.g. the test 'submodule update --merge - ignores --merge for new submodules' in 't7406-submodule-update.sh'. - Repetitive common tasks, including preparing the expected results and running 'test_cmp', are often extracted into a helper function, and some of this helper's callsites expect no output. - For the same reason as above, the whole 'test_expect_success' block is within a helper function, e.g. in 't3070-wildmatch.sh'. - Or 'test_cmp' is invoked in a loop, e.g. the test 'cvs update (-p)' in 't9400-git-cvsserver-server.sh'. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-19 21:57:25 +00:00
test_must_be_empty untracked
'
test_expect_success !CYGWIN 'submodule add with \\ in path' '
test_when_finished "rm -rf parent sub\\with\\backslash" &&
# Initialize a repo with a backslash in its name
git init sub\\with\\backslash &&
touch sub\\with\\backslash/empty.file &&
git -C sub\\with\\backslash add empty.file &&
git -C sub\\with\\backslash commit -m "Added empty.file" &&
# Add that repository as a submodule
git init parent &&
git -C parent submodule add ../sub\\with\\backslash
'
test_expect_success 'submodule add in subdirectory' '
echo "refs/heads/main" >expect &&
mkdir addtest/sub &&
(
cd addtest/sub &&
git submodule add "$submodurl" ../realsubmod3 &&
git submodule init
) &&
rm -f heads head untracked &&
inspect addtest/realsubmod3 ../.. &&
test_cmp expect heads &&
test_cmp expect head &&
tests: use 'test_must_be_empty' instead of 'test_cmp <empty> <out>' Using 'test_must_be_empty' is shorter and more idiomatic than >empty && test_cmp empty out as it saves the creation of an empty file. Furthermore, sometimes the expected empty file doesn't have such a descriptive name like 'empty', and its creation is far away from the place where it's finally used for comparison (e.g. in 't7600-merge.sh', where two expected empty files are created in the 'setup' test, but are used only about 500 lines later). These cases were found by instrumenting 'test_cmp' to error out the test script when it's used to compare empty files, and then converted manually. Note that even after this patch there still remain a lot of cases where we use 'test_cmp' to check empty files: - Sometimes the expected output is not hard-coded in the test, but 'test_cmp' is used to ensure that two similar git commands produce the same output, and that output happens to be empty, e.g. the test 'submodule update --merge - ignores --merge for new submodules' in 't7406-submodule-update.sh'. - Repetitive common tasks, including preparing the expected results and running 'test_cmp', are often extracted into a helper function, and some of this helper's callsites expect no output. - For the same reason as above, the whole 'test_expect_success' block is within a helper function, e.g. in 't3070-wildmatch.sh'. - Or 'test_cmp' is invoked in a loop, e.g. the test 'cvs update (-p)' in 't9400-git-cvsserver-server.sh'. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-19 21:57:25 +00:00
test_must_be_empty untracked
'
test_expect_success 'submodule add in subdirectory with relative path should fail' '
(
cd addtest/sub &&
test_must_fail git submodule add ../../ submod3 2>../../output.err
) &&
test_grep toplevel output.err
'
test_expect_success 'setup - add an example entry to .gitmodules' '
git config --file=.gitmodules submodule.example.url git://example.com/init.git
'
test_expect_success 'status should fail for unmapped paths' '
test_must_fail git submodule status
'
test_expect_success 'setup - map path in .gitmodules' '
cat <<\EOF >expect &&
[submodule "example"]
url = git://example.com/init.git
path = init
EOF
git config --file=.gitmodules submodule.example.path init &&
test_cmp expect .gitmodules
'
test_expect_success 'status should only print one line' '
git submodule status >lines &&
test_line_count = 1 lines
'
test_expect_success 'status from subdirectory should have the same SHA1' '
test_when_finished "rmdir addtest/subdir" &&
(
cd addtest &&
mkdir subdir &&
git submodule status >output &&
awk "{print \$1}" <output >expect &&
cd subdir &&
git submodule status >../output &&
awk "{print \$1}" <../output >../actual &&
test_cmp ../expect ../actual &&
git -C ../submod checkout HEAD^ &&
git submodule status >../output &&
awk "{print \$1}" <../output >../actual2 &&
cd .. &&
git submodule status >output &&
awk "{print \$1}" <output >expect2 &&
test_cmp expect2 actual2 &&
! test_cmp actual actual2
)
'
test_expect_success 'setup - fetch commit name from submodule' '
rev1=$(cd .subrepo && git rev-parse HEAD) &&
printf "rev1: %s\n" "$rev1" &&
test -n "$rev1"
'
test_expect_success 'status should initially be "missing"' '
git submodule status >lines &&
grep "^-$rev1" lines
'
test_expect_success 'init should register submodule url in .git/config' '
echo git://example.com/init.git >expect &&
git submodule init &&
git config submodule.example.url >url &&
git config submodule.example.url ./.subrepo &&
test_cmp expect url
'
test_expect_success 'status should still be "missing" after initializing' '
rm -fr init &&
mkdir init &&
git submodule status >lines &&
rm -fr init &&
grep "^-$rev1" lines
'
test_failure_with_unknown_submodule () {
test_must_fail git submodule $1 no-such-submodule 2>output.err &&
test_grep "^error: .*no-such-submodule" output.err
}
test_expect_success 'init should fail with unknown submodule' '
test_failure_with_unknown_submodule init
'
test_expect_success 'update should fail with unknown submodule' '
test_failure_with_unknown_submodule update
'
test_expect_success 'status should fail with unknown submodule' '
test_failure_with_unknown_submodule status
'
test_expect_success 'sync should fail with unknown submodule' '
test_failure_with_unknown_submodule sync
'
test_expect_success 'update should fail when path is used by a file' '
echo hello >expect &&
echo "hello" >init &&
test_must_fail git submodule update &&
test_cmp expect init
'
test_expect_success 'update should fail when path is used by a nonempty directory' '
echo hello >expect &&
rm -fr init &&
mkdir init &&
echo "hello" >init/a &&
test_must_fail git submodule update &&
test_cmp expect init/a
'
test_expect_success 'update should work when path is an empty dir' '
rm -fr init &&
rm -f head-sha1 &&
echo "$rev1" >expect &&
mkdir init &&
git submodule update -q >update.out &&
test_must_be_empty update.out &&
inspect init &&
test_cmp expect head-sha1
'
test_expect_success 'status should be "up-to-date" after update' '
git submodule status >list &&
grep "^ $rev1" list
'
test_expect_success 'status "up-to-date" from subdirectory' '
mkdir -p sub &&
(
cd sub &&
git submodule status >../list
) &&
grep "^ $rev1" list &&
grep "\\.\\./init" list
'
test_expect_success 'status "up-to-date" from subdirectory with path' '
mkdir -p sub &&
(
cd sub &&
git submodule status ../init >../list
) &&
grep "^ $rev1" list &&
grep "\\.\\./init" list
'
test_expect_success 'status should be "modified" after submodule commit' '
(
cd init &&
echo b >b &&
git add b &&
git commit -m "submodule commit 2"
) &&
rev2=$(cd init && git rev-parse HEAD) &&
test -n "$rev2" &&
git submodule status >list &&
grep "^+$rev2" list
'
test_expect_success '"submodule --cached" command forms should be identical' '
git submodule status --cached >expect &&
git submodule --cached >actual &&
test_cmp expect actual &&
git submodule --cached status >actual &&
test_cmp expect actual
'
test_expect_success 'the --cached sha1 should be rev1' '
git submodule --cached status >list &&
grep "^+$rev1" list
'
test_expect_success 'git diff should report the SHA1 of the new submodule commit' '
git diff >diff &&
grep "^+Subproject commit $rev2" diff
'
test_expect_success 'update should checkout rev1' '
rm -f head-sha1 &&
echo "$rev1" >expect &&
git submodule update init &&
inspect init &&
test_cmp expect head-sha1
'
test_expect_success 'status should be "up-to-date" after update' '
git submodule status >list &&
grep "^ $rev1" list
'
test_expect_success 'checkout superproject with subproject already present' '
git checkout initial &&
git checkout main
'
test_expect_success 'apply submodule diff' '
git branch second &&
(
cd init &&
echo s >s &&
git add s &&
git commit -m "change subproject"
) &&
git update-index --add init &&
git commit -m "change init" &&
git format-patch -1 --stdout >P.diff &&
git checkout second &&
git apply --index P.diff &&
git diff --cached main >staged &&
tests: use 'test_must_be_empty' instead of 'test_cmp <empty> <out>' Using 'test_must_be_empty' is shorter and more idiomatic than >empty && test_cmp empty out as it saves the creation of an empty file. Furthermore, sometimes the expected empty file doesn't have such a descriptive name like 'empty', and its creation is far away from the place where it's finally used for comparison (e.g. in 't7600-merge.sh', where two expected empty files are created in the 'setup' test, but are used only about 500 lines later). These cases were found by instrumenting 'test_cmp' to error out the test script when it's used to compare empty files, and then converted manually. Note that even after this patch there still remain a lot of cases where we use 'test_cmp' to check empty files: - Sometimes the expected output is not hard-coded in the test, but 'test_cmp' is used to ensure that two similar git commands produce the same output, and that output happens to be empty, e.g. the test 'submodule update --merge - ignores --merge for new submodules' in 't7406-submodule-update.sh'. - Repetitive common tasks, including preparing the expected results and running 'test_cmp', are often extracted into a helper function, and some of this helper's callsites expect no output. - For the same reason as above, the whole 'test_expect_success' block is within a helper function, e.g. in 't3070-wildmatch.sh'. - Or 'test_cmp' is invoked in a loop, e.g. the test 'cvs update (-p)' in 't9400-git-cvsserver-server.sh'. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-19 21:57:25 +00:00
test_must_be_empty staged
'
test_expect_success 'update --init' '
mv init init2 &&
git config -f .gitmodules submodule.example.url "$(pwd)/init2" &&
git config --remove-section submodule.example &&
test_must_fail git config submodule.example.url &&
git submodule update init 2> update.out &&
test_grep "not initialized" update.out &&
test_must_fail git rev-parse --resolve-git-dir init/.git &&
git submodule update --init init &&
git rev-parse --resolve-git-dir init/.git
'
test_expect_success 'update --init from subdirectory' '
mv init init2 &&
git config -f .gitmodules submodule.example.url "$(pwd)/init2" &&
git config --remove-section submodule.example &&
test_must_fail git config submodule.example.url &&
mkdir -p sub &&
(
cd sub &&
git submodule update ../init 2>update.out &&
test_grep "not initialized" update.out &&
test_must_fail git rev-parse --resolve-git-dir ../init/.git &&
git submodule update --init ../init
) &&
git rev-parse --resolve-git-dir init/.git
'
test_expect_success 'do not add files from a submodule' '
git reset --hard &&
test_must_fail git add init/a
'
test_expect_success 'gracefully add/reset submodule with a trailing slash' '
git reset --hard &&
git commit -m "commit subproject" init &&
(cd init &&
echo b > a) &&
git add init/ &&
git diff --exit-code --cached init &&
commit=$(cd init &&
git commit -m update a >/dev/null &&
git rev-parse HEAD) &&
git add init/ &&
test_must_fail git diff --exit-code --cached init &&
test $commit = $(git ls-files --stage |
sed -n "s/^160000 \([^ ]*\).*/\1/p") &&
git reset init/ &&
git diff --exit-code --cached init
'
test_expect_success 'ls-files gracefully handles trailing slash' '
test "init" = "$(git ls-files init/)"
'
test_expect_success 'moving to a commit without submodule does not leave empty dir' '
rm -rf init &&
mkdir init &&
git reset --hard &&
git checkout initial &&
test ! -d init &&
git checkout second
'
test_expect_success 'submodule <invalid-subcommand> fails' '
test_must_fail git submodule no-such-subcommand
'
test_expect_success 'add submodules without specifying an explicit path' '
mkdir repo &&
(
cd repo &&
git init &&
echo r >r &&
git add r &&
git commit -m "repo commit 1"
) &&
git clone --bare repo/ bare.git &&
(
cd addtest &&
git submodule add "$submodurl/repo" &&
git config -f .gitmodules submodule.repo.path repo &&
git submodule add "$submodurl/bare.git" &&
git config -f .gitmodules submodule.bare.path bare
)
'
test_expect_success 'add should fail when path is used by a file' '
(
cd addtest &&
touch file &&
test_must_fail git submodule add "$submodurl/repo" file
)
'
test_expect_success 'add should fail when path is used by an existing directory' '
(
cd addtest &&
mkdir empty-dir &&
test_must_fail git submodule add "$submodurl/repo" empty-dir
)
'
test_expect_success 'use superproject as upstream when path is relative and no url is set there' '
(
cd addtest &&
git submodule add ../repo relative &&
test "$(git config -f .gitmodules submodule.relative.url)" = ../repo &&
git submodule sync relative &&
test "$(git config submodule.relative.url)" = "$submodurl/repo"
)
'
test_expect_success 'set up for relative path tests' '
mkdir reltest &&
(
cd reltest &&
git init &&
mkdir sub &&
(
cd sub &&
git init &&
test_commit foo
) &&
git add sub &&
git config -f .gitmodules submodule.sub.path sub &&
git config -f .gitmodules submodule.sub.url ../subrepo &&
cp .git/config pristine-.git-config &&
cp .gitmodules pristine-.gitmodules
)
'
test_expect_success '../subrepo works with URL - ssh://hostname/repo' '
(
cd reltest &&
cp pristine-.git-config .git/config &&
cp pristine-.gitmodules .gitmodules &&
git config remote.origin.url ssh://hostname/repo &&
git submodule init &&
test "$(git config submodule.sub.url)" = ssh://hostname/subrepo
)
'
test_expect_success '../subrepo works with port-qualified URL - ssh://hostname:22/repo' '
(
cd reltest &&
cp pristine-.git-config .git/config &&
cp pristine-.gitmodules .gitmodules &&
git config remote.origin.url ssh://hostname:22/repo &&
git submodule init &&
test "$(git config submodule.sub.url)" = ssh://hostname:22/subrepo
)
'
# About the choice of the path in the next test:
# - double-slash side-steps path mangling issues on Windows
# - it is still an absolute local path
# - there cannot be a server with a blank in its name just in case the
# path is used erroneously to access a //server/share style path
test_expect_success '../subrepo path works with local path - //somewhere else/repo' '
(
cd reltest &&
cp pristine-.git-config .git/config &&
cp pristine-.gitmodules .gitmodules &&
git config remote.origin.url "//somewhere else/repo" &&
git submodule init &&
test "$(git config submodule.sub.url)" = "//somewhere else/subrepo"
)
'
test_expect_success '../subrepo works with file URL - file:///tmp/repo' '
(
cd reltest &&
cp pristine-.git-config .git/config &&
cp pristine-.gitmodules .gitmodules &&
git config remote.origin.url file:///tmp/repo &&
git submodule init &&
test "$(git config submodule.sub.url)" = file:///tmp/subrepo
)
'
test_expect_success '../subrepo works with helper URL- helper:://hostname/repo' '
(
cd reltest &&
cp pristine-.git-config .git/config &&
cp pristine-.gitmodules .gitmodules &&
git config remote.origin.url helper:://hostname/repo &&
git submodule init &&
test "$(git config submodule.sub.url)" = helper:://hostname/subrepo
)
'
test_expect_success '../subrepo works with scp-style URL - user@host:repo' '
(
cd reltest &&
cp pristine-.git-config .git/config &&
git config remote.origin.url user@host:repo &&
git submodule init &&
test "$(git config submodule.sub.url)" = user@host:subrepo
)
'
test_expect_success '../subrepo works with scp-style URL - user@host:path/to/repo' '
(
cd reltest &&
cp pristine-.git-config .git/config &&
cp pristine-.gitmodules .gitmodules &&
git config remote.origin.url user@host:path/to/repo &&
git submodule init &&
test "$(git config submodule.sub.url)" = user@host:path/to/subrepo
)
'
test_expect_success '../subrepo works with relative local path - foo' '
(
cd reltest &&
cp pristine-.git-config .git/config &&
cp pristine-.gitmodules .gitmodules &&
git config remote.origin.url foo &&
# actual: fails with an error
git submodule init &&
test "$(git config submodule.sub.url)" = subrepo
)
'
test_expect_success '../subrepo works with relative local path - foo/bar' '
(
cd reltest &&
cp pristine-.git-config .git/config &&
cp pristine-.gitmodules .gitmodules &&
git config remote.origin.url foo/bar &&
git submodule init &&
test "$(git config submodule.sub.url)" = foo/subrepo
)
'
test_expect_success '../subrepo works with relative local path - ./foo' '
(
cd reltest &&
cp pristine-.git-config .git/config &&
cp pristine-.gitmodules .gitmodules &&
git config remote.origin.url ./foo &&
git submodule init &&
test "$(git config submodule.sub.url)" = subrepo
)
'
test_expect_success '../subrepo works with relative local path - ./foo/bar' '
(
cd reltest &&
cp pristine-.git-config .git/config &&
cp pristine-.gitmodules .gitmodules &&
git config remote.origin.url ./foo/bar &&
git submodule init &&
test "$(git config submodule.sub.url)" = foo/subrepo
)
'
test_expect_success '../subrepo works with relative local path - ../foo' '
(
cd reltest &&
cp pristine-.git-config .git/config &&
cp pristine-.gitmodules .gitmodules &&
git config remote.origin.url ../foo &&
git submodule init &&
test "$(git config submodule.sub.url)" = ../subrepo
)
'
test_expect_success '../subrepo works with relative local path - ../foo/bar' '
(
cd reltest &&
cp pristine-.git-config .git/config &&
cp pristine-.gitmodules .gitmodules &&
git config remote.origin.url ../foo/bar &&
git submodule init &&
test "$(git config submodule.sub.url)" = ../foo/subrepo
)
'
test_expect_success '../bar/a/b/c works with relative local path - ../foo/bar.git' '
(
cd reltest &&
cp pristine-.git-config .git/config &&
cp pristine-.gitmodules .gitmodules &&
mkdir -p a/b/c &&
(cd a/b/c && git init && test_commit msg) &&
git config remote.origin.url ../foo/bar.git &&
git submodule add ../bar/a/b/c ./a/b/c &&
git submodule init &&
test "$(git config submodule.a/b/c.url)" = ../foo/bar/a/b/c
)
'
test_expect_success 'moving the superproject does not break submodules' '
(
cd addtest &&
git submodule status >expect
) &&
mv addtest addtest2 &&
(
cd addtest2 &&
git submodule status >actual &&
test_cmp expect actual
)
'
test_expect_success 'moving the submodule does not break the superproject' '
(
cd addtest2 &&
git submodule status
) >actual &&
sed -e "s/^ \([^ ]* repo\) .*/-\1/" <actual >expect &&
mv addtest2/repo addtest2/repo.bak &&
test_when_finished "mv addtest2/repo.bak addtest2/repo" &&
(
cd addtest2 &&
git submodule status
) >actual &&
test_cmp expect actual
'
test_expect_success 'submodule add --name allows to replace a submodule with another at the same path' '
(
cd addtest2 &&
(
cd repo &&
echo "$submodurl/repo" >expect &&
git config remote.origin.url >actual &&
test_cmp expect actual &&
echo "gitdir: ../.git/modules/repo" >expect &&
test_cmp expect .git
) &&
rm -rf repo &&
git rm repo &&
git submodule add -q --name repo_new "$submodurl/bare.git" repo >actual &&
test_must_be_empty actual &&
echo "gitdir: ../.git/modules/submod" >expect &&
test_cmp expect submod/.git &&
(
cd repo &&
echo "$submodurl/bare.git" >expect &&
git config remote.origin.url >actual &&
test_cmp expect actual &&
echo "gitdir: ../.git/modules/repo_new" >expect &&
test_cmp expect .git
) &&
echo "repo" >expect &&
rm: delete .gitmodules entry of submodules removed from the work tree Currently using "git rm" on a submodule removes the submodule's work tree from that of the superproject and the gitlink from the index. But the submodule's section in .gitmodules is left untouched, which is a leftover of the now removed submodule and might irritate users (as opposed to the setting in .git/config, this must stay as a reminder that the user showed interest in this submodule so it will be repopulated later when an older commit is checked out). Let "git rm" help the user by not only removing the submodule from the work tree but by also removing the "submodule.<submodule name>" section from the .gitmodules file and stage both. This doesn't happen when the "--cached" option is used, as it would modify the work tree. This also silently does nothing when no .gitmodules file is found and only issues a warning when it doesn't have a section for this submodule. This is because the user might just use plain gitlinks without the .gitmodules file or has already removed the section by hand before issuing the "git rm" command (in which case the warning reminds him that rm would have done that for him). Only when .gitmodules is found and contains merge conflicts the rm command will fail and tell the user to resolve the conflict before trying again. Also extend the man page to inform the user about this new feature. While at it promote the submodule sub-section to a chapter as it made not much sense under "REMOVING FILES THAT HAVE DISAPPEARED FROM THE FILESYSTEM". In t7610 three uses of "git rm submod" had to be replaced with "git rm --cached submod" because that test expects .gitmodules and the work tree to stay untouched. Also in t7400 the tests for the remaining settings in the .gitmodules file had to be changed to assert that these settings are missing. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-08-06 19:15:25 +00:00
test_must_fail git config -f .gitmodules submodule.repo.path &&
git config -f .gitmodules submodule.repo_new.path >actual &&
test_cmp expect actual &&
echo "$submodurl/repo" >expect &&
rm: delete .gitmodules entry of submodules removed from the work tree Currently using "git rm" on a submodule removes the submodule's work tree from that of the superproject and the gitlink from the index. But the submodule's section in .gitmodules is left untouched, which is a leftover of the now removed submodule and might irritate users (as opposed to the setting in .git/config, this must stay as a reminder that the user showed interest in this submodule so it will be repopulated later when an older commit is checked out). Let "git rm" help the user by not only removing the submodule from the work tree but by also removing the "submodule.<submodule name>" section from the .gitmodules file and stage both. This doesn't happen when the "--cached" option is used, as it would modify the work tree. This also silently does nothing when no .gitmodules file is found and only issues a warning when it doesn't have a section for this submodule. This is because the user might just use plain gitlinks without the .gitmodules file or has already removed the section by hand before issuing the "git rm" command (in which case the warning reminds him that rm would have done that for him). Only when .gitmodules is found and contains merge conflicts the rm command will fail and tell the user to resolve the conflict before trying again. Also extend the man page to inform the user about this new feature. While at it promote the submodule sub-section to a chapter as it made not much sense under "REMOVING FILES THAT HAVE DISAPPEARED FROM THE FILESYSTEM". In t7610 three uses of "git rm submod" had to be replaced with "git rm --cached submod" because that test expects .gitmodules and the work tree to stay untouched. Also in t7400 the tests for the remaining settings in the .gitmodules file had to be changed to assert that these settings are missing. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-08-06 19:15:25 +00:00
test_must_fail git config -f .gitmodules submodule.repo.url &&
echo "$submodurl/bare.git" >expect &&
git config -f .gitmodules submodule.repo_new.url >actual &&
test_cmp expect actual &&
echo "$submodurl/repo" >expect &&
git config submodule.repo.url >actual &&
test_cmp expect actual &&
echo "$submodurl/bare.git" >expect &&
git config submodule.repo_new.url >actual &&
test_cmp expect actual
)
'
test_expect_success 'recursive relative submodules stay relative' '
test_when_finished "rm -rf super clone2 subsub sub3" &&
mkdir subsub &&
(
cd subsub &&
git init &&
>t &&
git add t &&
git commit -m "initial commit"
) &&
mkdir sub3 &&
(
cd sub3 &&
git init &&
>t &&
git add t &&
git commit -m "initial commit" &&
git submodule add ../subsub dirdir/subsub &&
git commit -m "add submodule subsub"
) &&
mkdir super &&
(
cd super &&
git init &&
>t &&
git add t &&
git commit -m "initial commit" &&
git submodule add ../sub3 &&
git commit -m "add submodule sub"
) &&
git clone super clone2 &&
(
cd clone2 &&
git submodule update --init --recursive &&
echo "gitdir: ../.git/modules/sub3" >./sub3/.git_expect &&
echo "gitdir: ../../../.git/modules/sub3/modules/dirdir/subsub" >./sub3/dirdir/subsub/.git_expect
) &&
test_cmp clone2/sub3/.git_expect clone2/sub3/.git &&
test_cmp clone2/sub3/dirdir/subsub/.git_expect clone2/sub3/dirdir/subsub/.git
'
test_expect_success 'submodule add with an existing name fails unless forced' '
(
cd addtest2 &&
rm -rf repo &&
git rm repo &&
test_must_fail git submodule add -q --name repo_new "$submodurl/repo.git" repo &&
test ! -d repo &&
rm: delete .gitmodules entry of submodules removed from the work tree Currently using "git rm" on a submodule removes the submodule's work tree from that of the superproject and the gitlink from the index. But the submodule's section in .gitmodules is left untouched, which is a leftover of the now removed submodule and might irritate users (as opposed to the setting in .git/config, this must stay as a reminder that the user showed interest in this submodule so it will be repopulated later when an older commit is checked out). Let "git rm" help the user by not only removing the submodule from the work tree but by also removing the "submodule.<submodule name>" section from the .gitmodules file and stage both. This doesn't happen when the "--cached" option is used, as it would modify the work tree. This also silently does nothing when no .gitmodules file is found and only issues a warning when it doesn't have a section for this submodule. This is because the user might just use plain gitlinks without the .gitmodules file or has already removed the section by hand before issuing the "git rm" command (in which case the warning reminds him that rm would have done that for him). Only when .gitmodules is found and contains merge conflicts the rm command will fail and tell the user to resolve the conflict before trying again. Also extend the man page to inform the user about this new feature. While at it promote the submodule sub-section to a chapter as it made not much sense under "REMOVING FILES THAT HAVE DISAPPEARED FROM THE FILESYSTEM". In t7610 three uses of "git rm submod" had to be replaced with "git rm --cached submod" because that test expects .gitmodules and the work tree to stay untouched. Also in t7400 the tests for the remaining settings in the .gitmodules file had to be changed to assert that these settings are missing. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-08-06 19:15:25 +00:00
test_must_fail git config -f .gitmodules submodule.repo_new.path &&
test_must_fail git config -f .gitmodules submodule.repo_new.url &&
echo "$submodurl/bare.git" >expect &&
git config submodule.repo_new.url >actual &&
test_cmp expect actual &&
git submodule add -f -q --name repo_new "$submodurl/repo.git" repo &&
test -d repo &&
echo "repo" >expect &&
git config -f .gitmodules submodule.repo_new.path >actual &&
test_cmp expect actual &&
echo "$submodurl/repo.git" >expect &&
git config -f .gitmodules submodule.repo_new.url >actual &&
test_cmp expect actual &&
echo "$submodurl/repo.git" >expect &&
git config submodule.repo_new.url >actual &&
test_cmp expect actual
)
'
test_expect_success 'set up a second submodule' '
git submodule add ./init2 example2 &&
git commit -m "submodule example2 added"
'
test_expect_success 'submodule deinit works on repository without submodules' '
test_when_finished "rm -rf newdirectory" &&
mkdir newdirectory &&
(
cd newdirectory &&
git init &&
>file &&
git add file &&
git commit -m "repo should not be empty" &&
git submodule deinit . &&
git submodule deinit --all
)
'
test_expect_success 'submodule deinit should remove the whole submodule section from .git/config' '
git config submodule.example.foo bar &&
git config submodule.example2.frotz nitfol &&
git submodule deinit init &&
test -z "$(git config --get-regexp "submodule\.example\.")" &&
test -n "$(git config --get-regexp "submodule\.example2\.")" &&
test -f example2/.git &&
rmdir init
'
test_expect_success 'submodule deinit should unset core.worktree' '
test_path_is_file .git/modules/example/config &&
test_must_fail git config -f .git/modules/example/config core.worktree
'
test_expect_success 'submodule deinit from subdirectory' '
git submodule update --init &&
git config submodule.example.foo bar &&
mkdir -p sub &&
(
cd sub &&
git submodule deinit ../init >../output
) &&
test_grep "\\.\\./init" output &&
test -z "$(git config --get-regexp "submodule\.example\.")" &&
test -n "$(git config --get-regexp "submodule\.example2\.")" &&
test -f example2/.git &&
rmdir init
'
test_expect_success 'submodule deinit . deinits all initialized submodules' '
git submodule update --init &&
git config submodule.example.foo bar &&
git config submodule.example2.frotz nitfol &&
test_must_fail git submodule deinit &&
git submodule deinit . >actual &&
test -z "$(git config --get-regexp "submodule\.example\.")" &&
test -z "$(git config --get-regexp "submodule\.example2\.")" &&
test_grep "Cleared directory .init" actual &&
test_grep "Cleared directory .example2" actual &&
rmdir init example2
'
test_expect_success 'submodule deinit --all deinits all initialized submodules' '
git submodule update --init &&
git config submodule.example.foo bar &&
git config submodule.example2.frotz nitfol &&
test_must_fail git submodule deinit &&
git submodule deinit --all >actual &&
test -z "$(git config --get-regexp "submodule\.example\.")" &&
test -z "$(git config --get-regexp "submodule\.example2\.")" &&
test_grep "Cleared directory .init" actual &&
test_grep "Cleared directory .example2" actual &&
rmdir init example2
'
test_expect_success 'submodule deinit deinits a submodule when its work tree is missing or empty' '
git submodule update --init &&
rm -rf init example2/* example2/.git &&
git submodule deinit init example2 >actual &&
test -z "$(git config --get-regexp "submodule\.example\.")" &&
test -z "$(git config --get-regexp "submodule\.example2\.")" &&
test_grep ! "Cleared directory .init" actual &&
test_grep "Cleared directory .example2" actual &&
rmdir init
'
test_expect_success 'submodule deinit fails when the submodule contains modifications unless forced' '
git submodule update --init &&
echo X >>init/s &&
test_must_fail git submodule deinit init &&
test -n "$(git config --get-regexp "submodule\.example\.")" &&
test -f example2/.git &&
git submodule deinit -f init >actual &&
test -z "$(git config --get-regexp "submodule\.example\.")" &&
test_grep "Cleared directory .init" actual &&
rmdir init
'
test_expect_success 'submodule deinit fails when the submodule contains untracked files unless forced' '
git submodule update --init &&
echo X >>init/untracked &&
test_must_fail git submodule deinit init &&
test -n "$(git config --get-regexp "submodule\.example\.")" &&
test -f example2/.git &&
git submodule deinit -f init >actual &&
test -z "$(git config --get-regexp "submodule\.example\.")" &&
test_grep "Cleared directory .init" actual &&
rmdir init
'
test_expect_success 'submodule deinit fails when the submodule HEAD does not match unless forced' '
git submodule update --init &&
(
cd init &&
git checkout HEAD^
) &&
test_must_fail git submodule deinit init &&
test -n "$(git config --get-regexp "submodule\.example\.")" &&
test -f example2/.git &&
git submodule deinit -f init >actual &&
test -z "$(git config --get-regexp "submodule\.example\.")" &&
test_grep "Cleared directory .init" actual &&
rmdir init
'
test_expect_success 'submodule deinit is silent when used on an uninitialized submodule' '
git submodule update --init &&
git submodule deinit init >actual &&
test_grep "Submodule .example. (.*) unregistered for path .init" actual &&
test_grep "Cleared directory .init" actual &&
git submodule deinit init >actual &&
test_grep ! "Submodule .example. (.*) unregistered for path .init" actual &&
test_grep "Cleared directory .init" actual &&
git submodule deinit . >actual &&
test_grep ! "Submodule .example. (.*) unregistered for path .init" actual &&
test_grep "Submodule .example2. (.*) unregistered for path .example2" actual &&
test_grep "Cleared directory .init" actual &&
git submodule deinit . >actual &&
test_grep ! "Submodule .example. (.*) unregistered for path .init" actual &&
test_grep ! "Submodule .example2. (.*) unregistered for path .example2" actual &&
test_grep "Cleared directory .init" actual &&
git submodule deinit --all >actual &&
test_grep ! "Submodule .example. (.*) unregistered for path .init" actual &&
test_grep ! "Submodule .example2. (.*) unregistered for path .example2" actual &&
test_grep "Cleared directory .init" actual &&
rmdir init example2
'
test_expect_success 'submodule deinit absorbs .git directory if .git is a directory' '
git submodule update --init &&
(
cd init &&
rm .git &&
mv ../.git/modules/example .git &&
GIT_WORK_TREE=. git config --unset core.worktree
) &&
git submodule deinit init &&
test_path_is_missing init/.git &&
test -z "$(git config --get-regexp "submodule\.example\.")"
'
test_expect_success 'submodule with UTF-8 name' '
svname=$(printf "\303\245 \303\244\303\266") &&
mkdir "$svname" &&
(
cd "$svname" &&
git init &&
>sub &&
git add sub &&
git commit -m "init sub"
) &&
git submodule add ./"$svname" &&
git submodule >&2 &&
test -n "$(git submodule | grep "$svname")"
'
test_expect_success 'submodule add clone shallow submodule' '
mkdir super &&
pwd=$(pwd) &&
(
cd super &&
git init &&
git submodule add --depth=1 file://"$pwd"/example2 submodule &&
(
cd submodule &&
test 1 = $(git log --oneline | wc -l)
)
)
'
test_expect_success 'setup superproject with submodules' '
git init sub1 &&
test_commit -C sub1 test &&
test_commit -C sub1 test2 &&
git init multisuper &&
git -C multisuper submodule add ../sub1 sub0 &&
git -C multisuper submodule add ../sub1 sub1 &&
git -C multisuper submodule add ../sub1 sub2 &&
git -C multisuper submodule add ../sub1 sub3 &&
git -C multisuper commit -m "add some submodules"
'
cat >expect <<-EOF
-sub0
sub1 (test2)
sub2 (test2)
sub3 (test2)
EOF
test_expect_success 'submodule update --init with a specification' '
test_when_finished "rm -rf multisuper_clone" &&
pwd=$(pwd) &&
git clone file://"$pwd"/multisuper multisuper_clone &&
git -C multisuper_clone submodule update --init . ":(exclude)sub0" &&
git -C multisuper_clone submodule status | sed "s/$OID_REGEX //" >actual &&
test_cmp expect actual
'
test_expect_success 'submodule update --init with submodule.active set' '
test_when_finished "rm -rf multisuper_clone" &&
pwd=$(pwd) &&
git clone file://"$pwd"/multisuper multisuper_clone &&
git -C multisuper_clone config submodule.active "." &&
git -C multisuper_clone config --add submodule.active ":(exclude)sub0" &&
git -C multisuper_clone submodule update --init &&
git -C multisuper_clone submodule status | sed "s/$OID_REGEX //" >actual &&
test_cmp expect actual
'
test_expect_success 'submodule update and setting submodule.<name>.active' '
test_when_finished "rm -rf multisuper_clone" &&
pwd=$(pwd) &&
git clone file://"$pwd"/multisuper multisuper_clone &&
git -C multisuper_clone config --bool submodule.sub0.active "true" &&
git -C multisuper_clone config --bool submodule.sub1.active "false" &&
git -C multisuper_clone config --bool submodule.sub2.active "true" &&
cat >expect <<-\EOF &&
sub0 (test2)
-sub1
sub2 (test2)
-sub3
EOF
git -C multisuper_clone submodule update &&
git -C multisuper_clone submodule status | sed "s/$OID_REGEX //" >actual &&
test_cmp expect actual
'
submodule helper: convert relative URL to absolute URL if needed The submodule helper update_clone called by "git submodule update", clones submodules if needed. As submodules used to have the URL indicating if they were active, the step to resolve relative URLs was done in the "submodule init" step. Nowadays submodules can be configured active without calling an explicit init, e.g. via configuring submodule.active. When trying to obtain submodules that are set active this way, we'll fallback to the URL found in the .gitmodules, which may be relative to the superproject, but we do not resolve it, yet: git clone https://gerrit.googlesource.com/gerrit cd gerrit && grep url .gitmodules url = ../plugins/codemirror-editor ... git config submodule.active . git submodule update fatal: repository '../plugins/codemirror-editor' does not exist fatal: clone of '../plugins/codemirror-editor' into submodule path '/tmp/gerrit/plugins/codemirror-editor' failed Failed to clone 'plugins/codemirror-editor'. Retry scheduled [...] fatal: clone of '../plugins/codemirror-editor' into submodule path '/tmp/gerrit/plugins/codemirror-editor' failed Failed to clone 'plugins/codemirror-editor' a second time, aborting [...] To resolve the issue, factor out the function that resolves the relative URLs in "git submodule init" (in the submodule helper in the init_submodule function) and call it at the appropriate place in the update_clone helper. Reported-by: Jaewoong Jung <jungjw@google.com> Signed-off-by: Stefan Beller <sbeller@google.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-16 17:27:03 +00:00
test_expect_success 'clone active submodule without submodule url set' '
test_when_finished "rm -rf test/test" &&
mkdir test &&
# another dir breaks accidental relative paths still being correct
git clone file://"$pwd"/multisuper test/test &&
(
cd test/test &&
git config submodule.active "." &&
# do not pass --init flag, as the submodule is already active:
git submodule update &&
git submodule status >actual_raw &&
cut -d" " -f3- actual_raw >actual &&
submodule helper: convert relative URL to absolute URL if needed The submodule helper update_clone called by "git submodule update", clones submodules if needed. As submodules used to have the URL indicating if they were active, the step to resolve relative URLs was done in the "submodule init" step. Nowadays submodules can be configured active without calling an explicit init, e.g. via configuring submodule.active. When trying to obtain submodules that are set active this way, we'll fallback to the URL found in the .gitmodules, which may be relative to the superproject, but we do not resolve it, yet: git clone https://gerrit.googlesource.com/gerrit cd gerrit && grep url .gitmodules url = ../plugins/codemirror-editor ... git config submodule.active . git submodule update fatal: repository '../plugins/codemirror-editor' does not exist fatal: clone of '../plugins/codemirror-editor' into submodule path '/tmp/gerrit/plugins/codemirror-editor' failed Failed to clone 'plugins/codemirror-editor'. Retry scheduled [...] fatal: clone of '../plugins/codemirror-editor' into submodule path '/tmp/gerrit/plugins/codemirror-editor' failed Failed to clone 'plugins/codemirror-editor' a second time, aborting [...] To resolve the issue, factor out the function that resolves the relative URLs in "git submodule init" (in the submodule helper in the init_submodule function) and call it at the appropriate place in the update_clone helper. Reported-by: Jaewoong Jung <jungjw@google.com> Signed-off-by: Stefan Beller <sbeller@google.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-16 17:27:03 +00:00
cat >expect <<-\EOF &&
sub0 (test2)
sub1 (test2)
sub2 (test2)
sub3 (test2)
submodule helper: convert relative URL to absolute URL if needed The submodule helper update_clone called by "git submodule update", clones submodules if needed. As submodules used to have the URL indicating if they were active, the step to resolve relative URLs was done in the "submodule init" step. Nowadays submodules can be configured active without calling an explicit init, e.g. via configuring submodule.active. When trying to obtain submodules that are set active this way, we'll fallback to the URL found in the .gitmodules, which may be relative to the superproject, but we do not resolve it, yet: git clone https://gerrit.googlesource.com/gerrit cd gerrit && grep url .gitmodules url = ../plugins/codemirror-editor ... git config submodule.active . git submodule update fatal: repository '../plugins/codemirror-editor' does not exist fatal: clone of '../plugins/codemirror-editor' into submodule path '/tmp/gerrit/plugins/codemirror-editor' failed Failed to clone 'plugins/codemirror-editor'. Retry scheduled [...] fatal: clone of '../plugins/codemirror-editor' into submodule path '/tmp/gerrit/plugins/codemirror-editor' failed Failed to clone 'plugins/codemirror-editor' a second time, aborting [...] To resolve the issue, factor out the function that resolves the relative URLs in "git submodule init" (in the submodule helper in the init_submodule function) and call it at the appropriate place in the update_clone helper. Reported-by: Jaewoong Jung <jungjw@google.com> Signed-off-by: Stefan Beller <sbeller@google.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-16 17:27:03 +00:00
EOF
test_cmp expect actual
)
'
test_expect_success 'update submodules without url set in .gitconfig' '
test_when_finished "rm -rf multisuper_clone" &&
git clone file://"$pwd"/multisuper multisuper_clone &&
git -C multisuper_clone submodule init &&
for s in sub0 sub1 sub2 sub3
do
key=submodule.$s.url &&
git -C multisuper_clone config --local --unset $key &&
git -C multisuper_clone config --file .gitmodules --unset $key || return 1
done &&
test_must_fail git -C multisuper_clone submodule update 2>err &&
grep "cannot clone submodule .sub[0-3]. without a URL" err
'
test_expect_success 'clone --recurse-submodules with a pathspec works' '
test_when_finished "rm -rf multisuper_clone" &&
cat >expected <<-\EOF &&
sub0 (test2)
-sub1
-sub2
-sub3
EOF
git clone --recurse-submodules="sub0" multisuper multisuper_clone &&
git -C multisuper_clone submodule status | sed "s/$OID_REGEX //" >actual &&
test_cmp expected actual
'
test_expect_success 'clone with multiple --recurse-submodules options' '
test_when_finished "rm -rf multisuper_clone" &&
cat >expect <<-\EOF &&
-sub0
sub1 (test2)
-sub2
sub3 (test2)
EOF
git clone --recurse-submodules="." \
--recurse-submodules=":(exclude)sub0" \
--recurse-submodules=":(exclude)sub2" \
multisuper multisuper_clone &&
git -C multisuper_clone submodule status | sed "s/$OID_REGEX //" >actual &&
test_cmp expect actual
'
test_expect_success 'clone and subsequent updates correctly auto-initialize submodules' '
test_when_finished "rm -rf multisuper_clone" &&
cat <<-\EOF >expect &&
-sub0
sub1 (test2)
-sub2
sub3 (test2)
EOF
cat <<-\EOF >expect2 &&
-sub0
sub1 (test2)
-sub2
sub3 (test2)
-sub4
sub5 (test2)
EOF
git clone --recurse-submodules="." \
--recurse-submodules=":(exclude)sub0" \
--recurse-submodules=":(exclude)sub2" \
--recurse-submodules=":(exclude)sub4" \
multisuper multisuper_clone &&
git -C multisuper_clone submodule status | sed "s/$OID_REGEX //" >actual &&
test_cmp expect actual &&
git -C multisuper submodule add ../sub1 sub4 &&
git -C multisuper submodule add ../sub1 sub5 &&
git -C multisuper commit -m "add more submodules" &&
# obtain the new superproject
git -C multisuper_clone pull &&
git -C multisuper_clone submodule update --init &&
git -C multisuper_clone submodule status | sed "s/$OID_REGEX //" >actual &&
test_cmp expect2 actual
'
test_expect_success 'init properly sets the config' '
test_when_finished "rm -rf multisuper_clone" &&
git clone --recurse-submodules="." \
--recurse-submodules=":(exclude)sub0" \
multisuper multisuper_clone &&
git -C multisuper_clone submodule init -- sub0 sub1 &&
git -C multisuper_clone config --get submodule.sub0.active &&
test_must_fail git -C multisuper_clone config --get submodule.sub1.active
'
test_expect_success 'recursive clone respects -q' '
test_when_finished "rm -rf multisuper_clone" &&
git clone -q --recurse-submodules multisuper multisuper_clone >actual &&
test_must_be_empty actual
'
init.templateDir: consider this config setting protected The ability to configuring the template directory is a delicate feature: It allows defining hooks that will be run e.g. during a `git clone` operation, such as the `post-checkout` hook. As such, it is of utmost importance that Git would not allow that config setting to be changed during a `git clone` by mistake, allowing an attacker a chance for a Remote Code Execution, allowing attackers to run arbitrary code on unsuspecting users' machines. As a defense-in-depth measure, to prevent minor vulnerabilities in the `git clone` code from ballooning into higher-serverity attack vectors, let's make this a protected setting just like `safe.directory` and friends, i.e. ignore any `init.templateDir` entries from any local config. Note: This does not change the behavior of any recursive clone (modulo bugs), as the local repository config is not even supposed to be written while cloning the superproject, except in one scenario: If a config template is configured that sets the template directory. This might be done because `git clone --recurse-submodules --template=<directory>` does not pass that template directory on to the submodules' initialization. Another scenario where this commit changes behavior is where repositories are _not_ cloned recursively, and then some (intentional, benign) automation configures the template directory to be used before initializing the submodules. So the caveat is that this could theoretically break existing processes. In both scenarios, there is a way out, though: configuring the template directory via the environment variable `GIT_TEMPLATE_DIR`. This change in behavior is a trade-off between security and backwards-compatibility that is struck in favor of security. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2024-03-29 12:15:32 +00:00
test_expect_success '`submodule init` and `init.templateDir`' '
mkdir -p tmpl/hooks &&
write_script tmpl/hooks/post-checkout <<-EOF &&
echo HOOK-RUN >&2
echo I was here >hook.run
exit 1
EOF
test_config init.templateDir "$(pwd)/tmpl" &&
test_when_finished \
"git config --global --unset init.templateDir || true" &&
(
sane_unset GIT_TEMPLATE_DIR &&
NO_SET_GIT_TEMPLATE_DIR=t &&
export NO_SET_GIT_TEMPLATE_DIR &&
git config --global init.templateDir "$(pwd)/tmpl" &&
test_must_fail git submodule \
add "$submodurl" sub-global 2>err &&
git config --global --unset init.templateDir &&
test_grep HOOK-RUN err &&
init.templateDir: consider this config setting protected The ability to configuring the template directory is a delicate feature: It allows defining hooks that will be run e.g. during a `git clone` operation, such as the `post-checkout` hook. As such, it is of utmost importance that Git would not allow that config setting to be changed during a `git clone` by mistake, allowing an attacker a chance for a Remote Code Execution, allowing attackers to run arbitrary code on unsuspecting users' machines. As a defense-in-depth measure, to prevent minor vulnerabilities in the `git clone` code from ballooning into higher-serverity attack vectors, let's make this a protected setting just like `safe.directory` and friends, i.e. ignore any `init.templateDir` entries from any local config. Note: This does not change the behavior of any recursive clone (modulo bugs), as the local repository config is not even supposed to be written while cloning the superproject, except in one scenario: If a config template is configured that sets the template directory. This might be done because `git clone --recurse-submodules --template=<directory>` does not pass that template directory on to the submodules' initialization. Another scenario where this commit changes behavior is where repositories are _not_ cloned recursively, and then some (intentional, benign) automation configures the template directory to be used before initializing the submodules. So the caveat is that this could theoretically break existing processes. In both scenarios, there is a way out, though: configuring the template directory via the environment variable `GIT_TEMPLATE_DIR`. This change in behavior is a trade-off between security and backwards-compatibility that is struck in favor of security. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2024-03-29 12:15:32 +00:00
test_path_is_file sub-global/hook.run &&
git config init.templateDir "$(pwd)/tmpl" &&
git submodule add "$submodurl" sub-local 2>err &&
git config --unset init.templateDir &&
test_grep ! HOOK-RUN err &&
init.templateDir: consider this config setting protected The ability to configuring the template directory is a delicate feature: It allows defining hooks that will be run e.g. during a `git clone` operation, such as the `post-checkout` hook. As such, it is of utmost importance that Git would not allow that config setting to be changed during a `git clone` by mistake, allowing an attacker a chance for a Remote Code Execution, allowing attackers to run arbitrary code on unsuspecting users' machines. As a defense-in-depth measure, to prevent minor vulnerabilities in the `git clone` code from ballooning into higher-serverity attack vectors, let's make this a protected setting just like `safe.directory` and friends, i.e. ignore any `init.templateDir` entries from any local config. Note: This does not change the behavior of any recursive clone (modulo bugs), as the local repository config is not even supposed to be written while cloning the superproject, except in one scenario: If a config template is configured that sets the template directory. This might be done because `git clone --recurse-submodules --template=<directory>` does not pass that template directory on to the submodules' initialization. Another scenario where this commit changes behavior is where repositories are _not_ cloned recursively, and then some (intentional, benign) automation configures the template directory to be used before initializing the submodules. So the caveat is that this could theoretically break existing processes. In both scenarios, there is a way out, though: configuring the template directory via the environment variable `GIT_TEMPLATE_DIR`. This change in behavior is a trade-off between security and backwards-compatibility that is struck in favor of security. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2024-03-29 12:15:32 +00:00
test_path_is_missing sub-local/hook.run
)
'
test_done