git-commit-vandalism/t/t5526-fetch-submodules.sh

849 lines
24 KiB
Bash
Raw Normal View History

#!/bin/sh
# Copyright (c) 2010, Jens Lehmann
test_description='Recursive "git fetch" for submodules'
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-19 00:44:19 +01:00
GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=master
export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME
GIT_TEST_FATAL_REGISTER_SUBMODULE_ODB=1
export GIT_TEST_FATAL_REGISTER_SUBMODULE_ODB
. ./test-lib.sh
pwd=$(pwd)
add_upstream_commit() {
(
cd submodule &&
head1=$(git rev-parse --short HEAD) &&
echo new >> subfile &&
test_tick &&
git add subfile &&
git commit -m new subfile &&
head2=$(git rev-parse --short HEAD) &&
echo "Fetching submodule submodule" > ../expect.err &&
echo "From $pwd/submodule" >> ../expect.err &&
echo " $head1..$head2 sub -> origin/sub" >> ../expect.err
) &&
(
cd deepsubmodule &&
head1=$(git rev-parse --short HEAD) &&
echo new >> deepsubfile &&
test_tick &&
git add deepsubfile &&
git commit -m new deepsubfile &&
head2=$(git rev-parse --short HEAD) &&
echo "Fetching submodule submodule/subdir/deepsubmodule" >> ../expect.err
echo "From $pwd/deepsubmodule" >> ../expect.err &&
echo " $head1..$head2 deep -> origin/deep" >> ../expect.err
)
}
test_expect_success setup '
mkdir deepsubmodule &&
(
cd deepsubmodule &&
git init &&
echo deepsubcontent > deepsubfile &&
git add deepsubfile &&
git commit -m new deepsubfile &&
git branch -M deep
) &&
mkdir submodule &&
(
cd submodule &&
git init &&
echo subcontent > subfile &&
git add subfile &&
git submodule add "$pwd/deepsubmodule" subdir/deepsubmodule &&
git commit -a -m new &&
git branch -M sub
) &&
git submodule add "$pwd/submodule" submodule &&
git commit -am initial &&
git branch -M super &&
git clone . downstream &&
(
cd downstream &&
git submodule update --init --recursive
)
'
test_expect_success "fetch --recurse-submodules recurses into submodules" '
add_upstream_commit &&
(
cd downstream &&
git fetch --recurse-submodules >../actual.out 2>../actual.err
) &&
test_must_be_empty actual.out &&
test_cmp expect.err actual.err
'
test_expect_success "submodule.recurse option triggers recursive fetch" '
add_upstream_commit &&
(
cd downstream &&
git -c submodule.recurse fetch >../actual.out 2>../actual.err
) &&
test_must_be_empty actual.out &&
test_cmp expect.err actual.err
'
test_expect_success "fetch --recurse-submodules -j2 has the same output behaviour" '
add_upstream_commit &&
(
cd downstream &&
GIT_TRACE="$TRASH_DIRECTORY/trace.out" git fetch --recurse-submodules -j2 2>../actual.err
) &&
test_must_be_empty actual.out &&
test_cmp expect.err actual.err &&
grep "2 tasks" trace.out
'
test_expect_success "fetch alone only fetches superproject" '
add_upstream_commit &&
(
cd downstream &&
git fetch >../actual.out 2>../actual.err
) &&
test_must_be_empty actual.out &&
test_must_be_empty actual.err
'
test_expect_success "fetch --no-recurse-submodules only fetches superproject" '
(
cd downstream &&
git fetch --no-recurse-submodules >../actual.out 2>../actual.err
) &&
test_must_be_empty actual.out &&
test_must_be_empty actual.err
'
test_expect_success "using fetchRecurseSubmodules=true in .gitmodules recurses into submodules" '
(
cd downstream &&
git config -f .gitmodules submodule.submodule.fetchRecurseSubmodules true &&
git fetch >../actual.out 2>../actual.err
) &&
test_must_be_empty actual.out &&
test_cmp expect.err actual.err
'
test_expect_success "--no-recurse-submodules overrides .gitmodules config" '
add_upstream_commit &&
(
cd downstream &&
git fetch --no-recurse-submodules >../actual.out 2>../actual.err
) &&
test_must_be_empty actual.out &&
test_must_be_empty actual.err
'
test_expect_success "using fetchRecurseSubmodules=false in .git/config overrides setting in .gitmodules" '
(
cd downstream &&
git config submodule.submodule.fetchRecurseSubmodules false &&
git fetch >../actual.out 2>../actual.err
) &&
test_must_be_empty actual.out &&
test_must_be_empty actual.err
'
test_expect_success "--recurse-submodules overrides fetchRecurseSubmodules setting from .git/config" '
(
cd downstream &&
git fetch --recurse-submodules >../actual.out 2>../actual.err &&
git config --unset -f .gitmodules submodule.submodule.fetchRecurseSubmodules &&
git config --unset submodule.submodule.fetchRecurseSubmodules
) &&
test_must_be_empty actual.out &&
test_cmp expect.err actual.err
'
test_expect_success "--quiet propagates to submodules" '
(
cd downstream &&
git fetch --recurse-submodules --quiet >../actual.out 2>../actual.err
) &&
test_must_be_empty actual.out &&
test_must_be_empty actual.err
'
test_expect_success "--quiet propagates to parallel submodules" '
(
cd downstream &&
git fetch --recurse-submodules -j 2 --quiet >../actual.out 2>../actual.err
) &&
test_must_be_empty actual.out &&
test_must_be_empty actual.err
'
test_expect_success "--dry-run propagates to submodules" '
add_upstream_commit &&
(
cd downstream &&
git fetch --recurse-submodules --dry-run >../actual.out 2>../actual.err
) &&
test_must_be_empty actual.out &&
test_cmp expect.err actual.err
'
test_expect_success "Without --dry-run propagates to submodules" '
(
cd downstream &&
git fetch --recurse-submodules >../actual.out 2>../actual.err
) &&
test_must_be_empty actual.out &&
test_cmp expect.err actual.err
'
test_expect_success "recurseSubmodules=true propagates into submodules" '
add_upstream_commit &&
(
cd downstream &&
git config fetch.recurseSubmodules true &&
git fetch >../actual.out 2>../actual.err
) &&
test_must_be_empty actual.out &&
test_cmp expect.err actual.err
'
test_expect_success "--recurse-submodules overrides config in submodule" '
add_upstream_commit &&
(
cd downstream &&
(
cd submodule &&
git config fetch.recurseSubmodules false
) &&
git fetch --recurse-submodules >../actual.out 2>../actual.err
) &&
test_must_be_empty actual.out &&
test_cmp expect.err actual.err
'
test_expect_success "--no-recurse-submodules overrides config setting" '
add_upstream_commit &&
(
cd downstream &&
git config fetch.recurseSubmodules true &&
git fetch --no-recurse-submodules >../actual.out 2>../actual.err
) &&
test_must_be_empty actual.out &&
test_must_be_empty actual.err
'
test_expect_success "Recursion doesn't happen when no new commits are fetched in the superproject" '
fetch/pull: recurse into submodules when necessary To be able to access all commits of populated submodules referenced by the superproject it is sufficient to only then let "git fetch" recurse into a submodule when the new commits fetched in the superproject record new commits for it. Having these commits present is extremely useful when using the "--submodule" option to "git diff" (which is what "git gui" and "gitk" do since 1.6.6), as all submodule commits needed for creating a descriptive output can be accessed. Also merging submodule commits (added in 1.7.3) depends on the submodule commits in question being present to work. Last but not least this enables disconnected operation when using submodules, as all commits necessary for a successful "git submodule update -N" will have been fetched automatically. So we choose this mode as the default for fetch and pull. Before a new or changed ref from upstream is updated in update_local_ref() "git rev-list <new-sha1> --not --branches --remotes" is used to determine all newly fetched commits. These are then walked and diffed against their parent(s) to see if a submodule has been changed. If that is the case, its path is stored to be fetched after the superproject fetch is completed. Using the "--recurse-submodules" or the "--no-recurse-submodules" option disables the examination of the fetched refs because the result will be ignored anyway. There is currently no infrastructure for storing deleted and new submodules in the .git directory of the superproject. That's why fetch and pull for now only fetch submodules that are already checked out and are not renamed. In t7403 the "--no-recurse-submodules" argument had to be added to "git pull" to avoid failure because of the moved upstream submodule repo. Thanks-to: Jonathan Nieder <jrnieder@gmail.com> Thanks-to: Heiko Voigt <hvoigt@hvoigt.net> Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-06 23:10:46 +01:00
(
cd downstream &&
(
cd submodule &&
git config --unset fetch.recurseSubmodules
) &&
git config --unset fetch.recurseSubmodules &&
fetch/pull: recurse into submodules when necessary To be able to access all commits of populated submodules referenced by the superproject it is sufficient to only then let "git fetch" recurse into a submodule when the new commits fetched in the superproject record new commits for it. Having these commits present is extremely useful when using the "--submodule" option to "git diff" (which is what "git gui" and "gitk" do since 1.6.6), as all submodule commits needed for creating a descriptive output can be accessed. Also merging submodule commits (added in 1.7.3) depends on the submodule commits in question being present to work. Last but not least this enables disconnected operation when using submodules, as all commits necessary for a successful "git submodule update -N" will have been fetched automatically. So we choose this mode as the default for fetch and pull. Before a new or changed ref from upstream is updated in update_local_ref() "git rev-list <new-sha1> --not --branches --remotes" is used to determine all newly fetched commits. These are then walked and diffed against their parent(s) to see if a submodule has been changed. If that is the case, its path is stored to be fetched after the superproject fetch is completed. Using the "--recurse-submodules" or the "--no-recurse-submodules" option disables the examination of the fetched refs because the result will be ignored anyway. There is currently no infrastructure for storing deleted and new submodules in the .git directory of the superproject. That's why fetch and pull for now only fetch submodules that are already checked out and are not renamed. In t7403 the "--no-recurse-submodules" argument had to be added to "git pull" to avoid failure because of the moved upstream submodule repo. Thanks-to: Jonathan Nieder <jrnieder@gmail.com> Thanks-to: Heiko Voigt <hvoigt@hvoigt.net> Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-06 23:10:46 +01:00
git fetch >../actual.out 2>../actual.err
) &&
test_must_be_empty actual.out &&
test_must_be_empty actual.err
fetch/pull: recurse into submodules when necessary To be able to access all commits of populated submodules referenced by the superproject it is sufficient to only then let "git fetch" recurse into a submodule when the new commits fetched in the superproject record new commits for it. Having these commits present is extremely useful when using the "--submodule" option to "git diff" (which is what "git gui" and "gitk" do since 1.6.6), as all submodule commits needed for creating a descriptive output can be accessed. Also merging submodule commits (added in 1.7.3) depends on the submodule commits in question being present to work. Last but not least this enables disconnected operation when using submodules, as all commits necessary for a successful "git submodule update -N" will have been fetched automatically. So we choose this mode as the default for fetch and pull. Before a new or changed ref from upstream is updated in update_local_ref() "git rev-list <new-sha1> --not --branches --remotes" is used to determine all newly fetched commits. These are then walked and diffed against their parent(s) to see if a submodule has been changed. If that is the case, its path is stored to be fetched after the superproject fetch is completed. Using the "--recurse-submodules" or the "--no-recurse-submodules" option disables the examination of the fetched refs because the result will be ignored anyway. There is currently no infrastructure for storing deleted and new submodules in the .git directory of the superproject. That's why fetch and pull for now only fetch submodules that are already checked out and are not renamed. In t7403 the "--no-recurse-submodules" argument had to be added to "git pull" to avoid failure because of the moved upstream submodule repo. Thanks-to: Jonathan Nieder <jrnieder@gmail.com> Thanks-to: Heiko Voigt <hvoigt@hvoigt.net> Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-06 23:10:46 +01:00
'
test_expect_success "Recursion stops when no new submodule commits are fetched" '
fetch/pull: recurse into submodules when necessary To be able to access all commits of populated submodules referenced by the superproject it is sufficient to only then let "git fetch" recurse into a submodule when the new commits fetched in the superproject record new commits for it. Having these commits present is extremely useful when using the "--submodule" option to "git diff" (which is what "git gui" and "gitk" do since 1.6.6), as all submodule commits needed for creating a descriptive output can be accessed. Also merging submodule commits (added in 1.7.3) depends on the submodule commits in question being present to work. Last but not least this enables disconnected operation when using submodules, as all commits necessary for a successful "git submodule update -N" will have been fetched automatically. So we choose this mode as the default for fetch and pull. Before a new or changed ref from upstream is updated in update_local_ref() "git rev-list <new-sha1> --not --branches --remotes" is used to determine all newly fetched commits. These are then walked and diffed against their parent(s) to see if a submodule has been changed. If that is the case, its path is stored to be fetched after the superproject fetch is completed. Using the "--recurse-submodules" or the "--no-recurse-submodules" option disables the examination of the fetched refs because the result will be ignored anyway. There is currently no infrastructure for storing deleted and new submodules in the .git directory of the superproject. That's why fetch and pull for now only fetch submodules that are already checked out and are not renamed. In t7403 the "--no-recurse-submodules" argument had to be added to "git pull" to avoid failure because of the moved upstream submodule repo. Thanks-to: Jonathan Nieder <jrnieder@gmail.com> Thanks-to: Heiko Voigt <hvoigt@hvoigt.net> Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-06 23:10:46 +01:00
head1=$(git rev-parse --short HEAD) &&
git add submodule &&
git commit -m "new submodule" &&
head2=$(git rev-parse --short HEAD) &&
echo "From $pwd/." > expect.err.sub &&
echo " $head1..$head2 super -> origin/super" >>expect.err.sub &&
head -3 expect.err >> expect.err.sub &&
fetch/pull: recurse into submodules when necessary To be able to access all commits of populated submodules referenced by the superproject it is sufficient to only then let "git fetch" recurse into a submodule when the new commits fetched in the superproject record new commits for it. Having these commits present is extremely useful when using the "--submodule" option to "git diff" (which is what "git gui" and "gitk" do since 1.6.6), as all submodule commits needed for creating a descriptive output can be accessed. Also merging submodule commits (added in 1.7.3) depends on the submodule commits in question being present to work. Last but not least this enables disconnected operation when using submodules, as all commits necessary for a successful "git submodule update -N" will have been fetched automatically. So we choose this mode as the default for fetch and pull. Before a new or changed ref from upstream is updated in update_local_ref() "git rev-list <new-sha1> --not --branches --remotes" is used to determine all newly fetched commits. These are then walked and diffed against their parent(s) to see if a submodule has been changed. If that is the case, its path is stored to be fetched after the superproject fetch is completed. Using the "--recurse-submodules" or the "--no-recurse-submodules" option disables the examination of the fetched refs because the result will be ignored anyway. There is currently no infrastructure for storing deleted and new submodules in the .git directory of the superproject. That's why fetch and pull for now only fetch submodules that are already checked out and are not renamed. In t7403 the "--no-recurse-submodules" argument had to be added to "git pull" to avoid failure because of the moved upstream submodule repo. Thanks-to: Jonathan Nieder <jrnieder@gmail.com> Thanks-to: Heiko Voigt <hvoigt@hvoigt.net> Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-06 23:10:46 +01:00
(
cd downstream &&
git fetch >../actual.out 2>../actual.err
) &&
test_cmp expect.err.sub actual.err &&
test_must_be_empty actual.out
fetch/pull: recurse into submodules when necessary To be able to access all commits of populated submodules referenced by the superproject it is sufficient to only then let "git fetch" recurse into a submodule when the new commits fetched in the superproject record new commits for it. Having these commits present is extremely useful when using the "--submodule" option to "git diff" (which is what "git gui" and "gitk" do since 1.6.6), as all submodule commits needed for creating a descriptive output can be accessed. Also merging submodule commits (added in 1.7.3) depends on the submodule commits in question being present to work. Last but not least this enables disconnected operation when using submodules, as all commits necessary for a successful "git submodule update -N" will have been fetched automatically. So we choose this mode as the default for fetch and pull. Before a new or changed ref from upstream is updated in update_local_ref() "git rev-list <new-sha1> --not --branches --remotes" is used to determine all newly fetched commits. These are then walked and diffed against their parent(s) to see if a submodule has been changed. If that is the case, its path is stored to be fetched after the superproject fetch is completed. Using the "--recurse-submodules" or the "--no-recurse-submodules" option disables the examination of the fetched refs because the result will be ignored anyway. There is currently no infrastructure for storing deleted and new submodules in the .git directory of the superproject. That's why fetch and pull for now only fetch submodules that are already checked out and are not renamed. In t7403 the "--no-recurse-submodules" argument had to be added to "git pull" to avoid failure because of the moved upstream submodule repo. Thanks-to: Jonathan Nieder <jrnieder@gmail.com> Thanks-to: Heiko Voigt <hvoigt@hvoigt.net> Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-06 23:10:46 +01:00
'
test_expect_success "Recursion doesn't happen when new superproject commits don't change any submodules" '
fetch/pull: recurse into submodules when necessary To be able to access all commits of populated submodules referenced by the superproject it is sufficient to only then let "git fetch" recurse into a submodule when the new commits fetched in the superproject record new commits for it. Having these commits present is extremely useful when using the "--submodule" option to "git diff" (which is what "git gui" and "gitk" do since 1.6.6), as all submodule commits needed for creating a descriptive output can be accessed. Also merging submodule commits (added in 1.7.3) depends on the submodule commits in question being present to work. Last but not least this enables disconnected operation when using submodules, as all commits necessary for a successful "git submodule update -N" will have been fetched automatically. So we choose this mode as the default for fetch and pull. Before a new or changed ref from upstream is updated in update_local_ref() "git rev-list <new-sha1> --not --branches --remotes" is used to determine all newly fetched commits. These are then walked and diffed against their parent(s) to see if a submodule has been changed. If that is the case, its path is stored to be fetched after the superproject fetch is completed. Using the "--recurse-submodules" or the "--no-recurse-submodules" option disables the examination of the fetched refs because the result will be ignored anyway. There is currently no infrastructure for storing deleted and new submodules in the .git directory of the superproject. That's why fetch and pull for now only fetch submodules that are already checked out and are not renamed. In t7403 the "--no-recurse-submodules" argument had to be added to "git pull" to avoid failure because of the moved upstream submodule repo. Thanks-to: Jonathan Nieder <jrnieder@gmail.com> Thanks-to: Heiko Voigt <hvoigt@hvoigt.net> Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-06 23:10:46 +01:00
add_upstream_commit &&
head1=$(git rev-parse --short HEAD) &&
echo a > file &&
git add file &&
git commit -m "new file" &&
head2=$(git rev-parse --short HEAD) &&
echo "From $pwd/." > expect.err.file &&
echo " $head1..$head2 super -> origin/super" >> expect.err.file &&
fetch/pull: recurse into submodules when necessary To be able to access all commits of populated submodules referenced by the superproject it is sufficient to only then let "git fetch" recurse into a submodule when the new commits fetched in the superproject record new commits for it. Having these commits present is extremely useful when using the "--submodule" option to "git diff" (which is what "git gui" and "gitk" do since 1.6.6), as all submodule commits needed for creating a descriptive output can be accessed. Also merging submodule commits (added in 1.7.3) depends on the submodule commits in question being present to work. Last but not least this enables disconnected operation when using submodules, as all commits necessary for a successful "git submodule update -N" will have been fetched automatically. So we choose this mode as the default for fetch and pull. Before a new or changed ref from upstream is updated in update_local_ref() "git rev-list <new-sha1> --not --branches --remotes" is used to determine all newly fetched commits. These are then walked and diffed against their parent(s) to see if a submodule has been changed. If that is the case, its path is stored to be fetched after the superproject fetch is completed. Using the "--recurse-submodules" or the "--no-recurse-submodules" option disables the examination of the fetched refs because the result will be ignored anyway. There is currently no infrastructure for storing deleted and new submodules in the .git directory of the superproject. That's why fetch and pull for now only fetch submodules that are already checked out and are not renamed. In t7403 the "--no-recurse-submodules" argument had to be added to "git pull" to avoid failure because of the moved upstream submodule repo. Thanks-to: Jonathan Nieder <jrnieder@gmail.com> Thanks-to: Heiko Voigt <hvoigt@hvoigt.net> Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-06 23:10:46 +01:00
(
cd downstream &&
git fetch >../actual.out 2>../actual.err
) &&
test_must_be_empty actual.out &&
test_cmp expect.err.file actual.err
fetch/pull: recurse into submodules when necessary To be able to access all commits of populated submodules referenced by the superproject it is sufficient to only then let "git fetch" recurse into a submodule when the new commits fetched in the superproject record new commits for it. Having these commits present is extremely useful when using the "--submodule" option to "git diff" (which is what "git gui" and "gitk" do since 1.6.6), as all submodule commits needed for creating a descriptive output can be accessed. Also merging submodule commits (added in 1.7.3) depends on the submodule commits in question being present to work. Last but not least this enables disconnected operation when using submodules, as all commits necessary for a successful "git submodule update -N" will have been fetched automatically. So we choose this mode as the default for fetch and pull. Before a new or changed ref from upstream is updated in update_local_ref() "git rev-list <new-sha1> --not --branches --remotes" is used to determine all newly fetched commits. These are then walked and diffed against their parent(s) to see if a submodule has been changed. If that is the case, its path is stored to be fetched after the superproject fetch is completed. Using the "--recurse-submodules" or the "--no-recurse-submodules" option disables the examination of the fetched refs because the result will be ignored anyway. There is currently no infrastructure for storing deleted and new submodules in the .git directory of the superproject. That's why fetch and pull for now only fetch submodules that are already checked out and are not renamed. In t7403 the "--no-recurse-submodules" argument had to be added to "git pull" to avoid failure because of the moved upstream submodule repo. Thanks-to: Jonathan Nieder <jrnieder@gmail.com> Thanks-to: Heiko Voigt <hvoigt@hvoigt.net> Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-06 23:10:46 +01:00
'
test_expect_success "Recursion picks up config in submodule" '
fetch/pull: recurse into submodules when necessary To be able to access all commits of populated submodules referenced by the superproject it is sufficient to only then let "git fetch" recurse into a submodule when the new commits fetched in the superproject record new commits for it. Having these commits present is extremely useful when using the "--submodule" option to "git diff" (which is what "git gui" and "gitk" do since 1.6.6), as all submodule commits needed for creating a descriptive output can be accessed. Also merging submodule commits (added in 1.7.3) depends on the submodule commits in question being present to work. Last but not least this enables disconnected operation when using submodules, as all commits necessary for a successful "git submodule update -N" will have been fetched automatically. So we choose this mode as the default for fetch and pull. Before a new or changed ref from upstream is updated in update_local_ref() "git rev-list <new-sha1> --not --branches --remotes" is used to determine all newly fetched commits. These are then walked and diffed against their parent(s) to see if a submodule has been changed. If that is the case, its path is stored to be fetched after the superproject fetch is completed. Using the "--recurse-submodules" or the "--no-recurse-submodules" option disables the examination of the fetched refs because the result will be ignored anyway. There is currently no infrastructure for storing deleted and new submodules in the .git directory of the superproject. That's why fetch and pull for now only fetch submodules that are already checked out and are not renamed. In t7403 the "--no-recurse-submodules" argument had to be added to "git pull" to avoid failure because of the moved upstream submodule repo. Thanks-to: Jonathan Nieder <jrnieder@gmail.com> Thanks-to: Heiko Voigt <hvoigt@hvoigt.net> Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-06 23:10:46 +01:00
(
cd downstream &&
git fetch --recurse-submodules &&
(
cd submodule &&
git config fetch.recurseSubmodules true
)
) &&
add_upstream_commit &&
head1=$(git rev-parse --short HEAD) &&
git add submodule &&
git commit -m "new submodule" &&
head2=$(git rev-parse --short HEAD) &&
echo "From $pwd/." > expect.err.sub &&
echo " $head1..$head2 super -> origin/super" >> expect.err.sub &&
fetch/pull: recurse into submodules when necessary To be able to access all commits of populated submodules referenced by the superproject it is sufficient to only then let "git fetch" recurse into a submodule when the new commits fetched in the superproject record new commits for it. Having these commits present is extremely useful when using the "--submodule" option to "git diff" (which is what "git gui" and "gitk" do since 1.6.6), as all submodule commits needed for creating a descriptive output can be accessed. Also merging submodule commits (added in 1.7.3) depends on the submodule commits in question being present to work. Last but not least this enables disconnected operation when using submodules, as all commits necessary for a successful "git submodule update -N" will have been fetched automatically. So we choose this mode as the default for fetch and pull. Before a new or changed ref from upstream is updated in update_local_ref() "git rev-list <new-sha1> --not --branches --remotes" is used to determine all newly fetched commits. These are then walked and diffed against their parent(s) to see if a submodule has been changed. If that is the case, its path is stored to be fetched after the superproject fetch is completed. Using the "--recurse-submodules" or the "--no-recurse-submodules" option disables the examination of the fetched refs because the result will be ignored anyway. There is currently no infrastructure for storing deleted and new submodules in the .git directory of the superproject. That's why fetch and pull for now only fetch submodules that are already checked out and are not renamed. In t7403 the "--no-recurse-submodules" argument had to be added to "git pull" to avoid failure because of the moved upstream submodule repo. Thanks-to: Jonathan Nieder <jrnieder@gmail.com> Thanks-to: Heiko Voigt <hvoigt@hvoigt.net> Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-06 23:10:46 +01:00
cat expect.err >> expect.err.sub &&
(
cd downstream &&
git fetch >../actual.out 2>../actual.err &&
(
cd submodule &&
git config --unset fetch.recurseSubmodules
)
) &&
test_cmp expect.err.sub actual.err &&
test_must_be_empty actual.out
fetch/pull: recurse into submodules when necessary To be able to access all commits of populated submodules referenced by the superproject it is sufficient to only then let "git fetch" recurse into a submodule when the new commits fetched in the superproject record new commits for it. Having these commits present is extremely useful when using the "--submodule" option to "git diff" (which is what "git gui" and "gitk" do since 1.6.6), as all submodule commits needed for creating a descriptive output can be accessed. Also merging submodule commits (added in 1.7.3) depends on the submodule commits in question being present to work. Last but not least this enables disconnected operation when using submodules, as all commits necessary for a successful "git submodule update -N" will have been fetched automatically. So we choose this mode as the default for fetch and pull. Before a new or changed ref from upstream is updated in update_local_ref() "git rev-list <new-sha1> --not --branches --remotes" is used to determine all newly fetched commits. These are then walked and diffed against their parent(s) to see if a submodule has been changed. If that is the case, its path is stored to be fetched after the superproject fetch is completed. Using the "--recurse-submodules" or the "--no-recurse-submodules" option disables the examination of the fetched refs because the result will be ignored anyway. There is currently no infrastructure for storing deleted and new submodules in the .git directory of the superproject. That's why fetch and pull for now only fetch submodules that are already checked out and are not renamed. In t7403 the "--no-recurse-submodules" argument had to be added to "git pull" to avoid failure because of the moved upstream submodule repo. Thanks-to: Jonathan Nieder <jrnieder@gmail.com> Thanks-to: Heiko Voigt <hvoigt@hvoigt.net> Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-06 23:10:46 +01:00
'
test_expect_success "Recursion picks up all submodules when necessary" '
fetch/pull: recurse into submodules when necessary To be able to access all commits of populated submodules referenced by the superproject it is sufficient to only then let "git fetch" recurse into a submodule when the new commits fetched in the superproject record new commits for it. Having these commits present is extremely useful when using the "--submodule" option to "git diff" (which is what "git gui" and "gitk" do since 1.6.6), as all submodule commits needed for creating a descriptive output can be accessed. Also merging submodule commits (added in 1.7.3) depends on the submodule commits in question being present to work. Last but not least this enables disconnected operation when using submodules, as all commits necessary for a successful "git submodule update -N" will have been fetched automatically. So we choose this mode as the default for fetch and pull. Before a new or changed ref from upstream is updated in update_local_ref() "git rev-list <new-sha1> --not --branches --remotes" is used to determine all newly fetched commits. These are then walked and diffed against their parent(s) to see if a submodule has been changed. If that is the case, its path is stored to be fetched after the superproject fetch is completed. Using the "--recurse-submodules" or the "--no-recurse-submodules" option disables the examination of the fetched refs because the result will be ignored anyway. There is currently no infrastructure for storing deleted and new submodules in the .git directory of the superproject. That's why fetch and pull for now only fetch submodules that are already checked out and are not renamed. In t7403 the "--no-recurse-submodules" argument had to be added to "git pull" to avoid failure because of the moved upstream submodule repo. Thanks-to: Jonathan Nieder <jrnieder@gmail.com> Thanks-to: Heiko Voigt <hvoigt@hvoigt.net> Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-06 23:10:46 +01:00
add_upstream_commit &&
(
cd submodule &&
(
cd subdir/deepsubmodule &&
fetch/pull: recurse into submodules when necessary To be able to access all commits of populated submodules referenced by the superproject it is sufficient to only then let "git fetch" recurse into a submodule when the new commits fetched in the superproject record new commits for it. Having these commits present is extremely useful when using the "--submodule" option to "git diff" (which is what "git gui" and "gitk" do since 1.6.6), as all submodule commits needed for creating a descriptive output can be accessed. Also merging submodule commits (added in 1.7.3) depends on the submodule commits in question being present to work. Last but not least this enables disconnected operation when using submodules, as all commits necessary for a successful "git submodule update -N" will have been fetched automatically. So we choose this mode as the default for fetch and pull. Before a new or changed ref from upstream is updated in update_local_ref() "git rev-list <new-sha1> --not --branches --remotes" is used to determine all newly fetched commits. These are then walked and diffed against their parent(s) to see if a submodule has been changed. If that is the case, its path is stored to be fetched after the superproject fetch is completed. Using the "--recurse-submodules" or the "--no-recurse-submodules" option disables the examination of the fetched refs because the result will be ignored anyway. There is currently no infrastructure for storing deleted and new submodules in the .git directory of the superproject. That's why fetch and pull for now only fetch submodules that are already checked out and are not renamed. In t7403 the "--no-recurse-submodules" argument had to be added to "git pull" to avoid failure because of the moved upstream submodule repo. Thanks-to: Jonathan Nieder <jrnieder@gmail.com> Thanks-to: Heiko Voigt <hvoigt@hvoigt.net> Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-06 23:10:46 +01:00
git fetch &&
git checkout -q FETCH_HEAD
) &&
head1=$(git rev-parse --short HEAD^) &&
git add subdir/deepsubmodule &&
git commit -m "new deepsubmodule" &&
fetch/pull: recurse into submodules when necessary To be able to access all commits of populated submodules referenced by the superproject it is sufficient to only then let "git fetch" recurse into a submodule when the new commits fetched in the superproject record new commits for it. Having these commits present is extremely useful when using the "--submodule" option to "git diff" (which is what "git gui" and "gitk" do since 1.6.6), as all submodule commits needed for creating a descriptive output can be accessed. Also merging submodule commits (added in 1.7.3) depends on the submodule commits in question being present to work. Last but not least this enables disconnected operation when using submodules, as all commits necessary for a successful "git submodule update -N" will have been fetched automatically. So we choose this mode as the default for fetch and pull. Before a new or changed ref from upstream is updated in update_local_ref() "git rev-list <new-sha1> --not --branches --remotes" is used to determine all newly fetched commits. These are then walked and diffed against their parent(s) to see if a submodule has been changed. If that is the case, its path is stored to be fetched after the superproject fetch is completed. Using the "--recurse-submodules" or the "--no-recurse-submodules" option disables the examination of the fetched refs because the result will be ignored anyway. There is currently no infrastructure for storing deleted and new submodules in the .git directory of the superproject. That's why fetch and pull for now only fetch submodules that are already checked out and are not renamed. In t7403 the "--no-recurse-submodules" argument had to be added to "git pull" to avoid failure because of the moved upstream submodule repo. Thanks-to: Jonathan Nieder <jrnieder@gmail.com> Thanks-to: Heiko Voigt <hvoigt@hvoigt.net> Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-06 23:10:46 +01:00
head2=$(git rev-parse --short HEAD) &&
echo "Fetching submodule submodule" > ../expect.err.sub &&
echo "From $pwd/submodule" >> ../expect.err.sub &&
echo " $head1..$head2 sub -> origin/sub" >> ../expect.err.sub
fetch/pull: recurse into submodules when necessary To be able to access all commits of populated submodules referenced by the superproject it is sufficient to only then let "git fetch" recurse into a submodule when the new commits fetched in the superproject record new commits for it. Having these commits present is extremely useful when using the "--submodule" option to "git diff" (which is what "git gui" and "gitk" do since 1.6.6), as all submodule commits needed for creating a descriptive output can be accessed. Also merging submodule commits (added in 1.7.3) depends on the submodule commits in question being present to work. Last but not least this enables disconnected operation when using submodules, as all commits necessary for a successful "git submodule update -N" will have been fetched automatically. So we choose this mode as the default for fetch and pull. Before a new or changed ref from upstream is updated in update_local_ref() "git rev-list <new-sha1> --not --branches --remotes" is used to determine all newly fetched commits. These are then walked and diffed against their parent(s) to see if a submodule has been changed. If that is the case, its path is stored to be fetched after the superproject fetch is completed. Using the "--recurse-submodules" or the "--no-recurse-submodules" option disables the examination of the fetched refs because the result will be ignored anyway. There is currently no infrastructure for storing deleted and new submodules in the .git directory of the superproject. That's why fetch and pull for now only fetch submodules that are already checked out and are not renamed. In t7403 the "--no-recurse-submodules" argument had to be added to "git pull" to avoid failure because of the moved upstream submodule repo. Thanks-to: Jonathan Nieder <jrnieder@gmail.com> Thanks-to: Heiko Voigt <hvoigt@hvoigt.net> Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-06 23:10:46 +01:00
) &&
head1=$(git rev-parse --short HEAD) &&
git add submodule &&
git commit -m "new submodule" &&
head2=$(git rev-parse --short HEAD) &&
echo "From $pwd/." > expect.err.2 &&
echo " $head1..$head2 super -> origin/super" >> expect.err.2 &&
fetch/pull: recurse into submodules when necessary To be able to access all commits of populated submodules referenced by the superproject it is sufficient to only then let "git fetch" recurse into a submodule when the new commits fetched in the superproject record new commits for it. Having these commits present is extremely useful when using the "--submodule" option to "git diff" (which is what "git gui" and "gitk" do since 1.6.6), as all submodule commits needed for creating a descriptive output can be accessed. Also merging submodule commits (added in 1.7.3) depends on the submodule commits in question being present to work. Last but not least this enables disconnected operation when using submodules, as all commits necessary for a successful "git submodule update -N" will have been fetched automatically. So we choose this mode as the default for fetch and pull. Before a new or changed ref from upstream is updated in update_local_ref() "git rev-list <new-sha1> --not --branches --remotes" is used to determine all newly fetched commits. These are then walked and diffed against their parent(s) to see if a submodule has been changed. If that is the case, its path is stored to be fetched after the superproject fetch is completed. Using the "--recurse-submodules" or the "--no-recurse-submodules" option disables the examination of the fetched refs because the result will be ignored anyway. There is currently no infrastructure for storing deleted and new submodules in the .git directory of the superproject. That's why fetch and pull for now only fetch submodules that are already checked out and are not renamed. In t7403 the "--no-recurse-submodules" argument had to be added to "git pull" to avoid failure because of the moved upstream submodule repo. Thanks-to: Jonathan Nieder <jrnieder@gmail.com> Thanks-to: Heiko Voigt <hvoigt@hvoigt.net> Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-06 23:10:46 +01:00
cat expect.err.sub >> expect.err.2 &&
tail -3 expect.err >> expect.err.2 &&
fetch/pull: recurse into submodules when necessary To be able to access all commits of populated submodules referenced by the superproject it is sufficient to only then let "git fetch" recurse into a submodule when the new commits fetched in the superproject record new commits for it. Having these commits present is extremely useful when using the "--submodule" option to "git diff" (which is what "git gui" and "gitk" do since 1.6.6), as all submodule commits needed for creating a descriptive output can be accessed. Also merging submodule commits (added in 1.7.3) depends on the submodule commits in question being present to work. Last but not least this enables disconnected operation when using submodules, as all commits necessary for a successful "git submodule update -N" will have been fetched automatically. So we choose this mode as the default for fetch and pull. Before a new or changed ref from upstream is updated in update_local_ref() "git rev-list <new-sha1> --not --branches --remotes" is used to determine all newly fetched commits. These are then walked and diffed against their parent(s) to see if a submodule has been changed. If that is the case, its path is stored to be fetched after the superproject fetch is completed. Using the "--recurse-submodules" or the "--no-recurse-submodules" option disables the examination of the fetched refs because the result will be ignored anyway. There is currently no infrastructure for storing deleted and new submodules in the .git directory of the superproject. That's why fetch and pull for now only fetch submodules that are already checked out and are not renamed. In t7403 the "--no-recurse-submodules" argument had to be added to "git pull" to avoid failure because of the moved upstream submodule repo. Thanks-to: Jonathan Nieder <jrnieder@gmail.com> Thanks-to: Heiko Voigt <hvoigt@hvoigt.net> Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-06 23:10:46 +01:00
(
cd downstream &&
git fetch >../actual.out 2>../actual.err
) &&
test_cmp expect.err.2 actual.err &&
test_must_be_empty actual.out
fetch/pull: recurse into submodules when necessary To be able to access all commits of populated submodules referenced by the superproject it is sufficient to only then let "git fetch" recurse into a submodule when the new commits fetched in the superproject record new commits for it. Having these commits present is extremely useful when using the "--submodule" option to "git diff" (which is what "git gui" and "gitk" do since 1.6.6), as all submodule commits needed for creating a descriptive output can be accessed. Also merging submodule commits (added in 1.7.3) depends on the submodule commits in question being present to work. Last but not least this enables disconnected operation when using submodules, as all commits necessary for a successful "git submodule update -N" will have been fetched automatically. So we choose this mode as the default for fetch and pull. Before a new or changed ref from upstream is updated in update_local_ref() "git rev-list <new-sha1> --not --branches --remotes" is used to determine all newly fetched commits. These are then walked and diffed against their parent(s) to see if a submodule has been changed. If that is the case, its path is stored to be fetched after the superproject fetch is completed. Using the "--recurse-submodules" or the "--no-recurse-submodules" option disables the examination of the fetched refs because the result will be ignored anyway. There is currently no infrastructure for storing deleted and new submodules in the .git directory of the superproject. That's why fetch and pull for now only fetch submodules that are already checked out and are not renamed. In t7403 the "--no-recurse-submodules" argument had to be added to "git pull" to avoid failure because of the moved upstream submodule repo. Thanks-to: Jonathan Nieder <jrnieder@gmail.com> Thanks-to: Heiko Voigt <hvoigt@hvoigt.net> Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-06 23:10:46 +01:00
'
test_expect_success "'--recurse-submodules=on-demand' doesn't recurse when no new commits are fetched in the superproject (and ignores config)" '
add_upstream_commit &&
(
cd submodule &&
(
cd subdir/deepsubmodule &&
git fetch &&
git checkout -q FETCH_HEAD
) &&
head1=$(git rev-parse --short HEAD^) &&
git add subdir/deepsubmodule &&
git commit -m "new deepsubmodule" &&
head2=$(git rev-parse --short HEAD) &&
echo Fetching submodule submodule > ../expect.err.sub &&
echo "From $pwd/submodule" >> ../expect.err.sub &&
echo " $head1..$head2 sub -> origin/sub" >> ../expect.err.sub
) &&
(
cd downstream &&
git config fetch.recurseSubmodules true &&
git fetch --recurse-submodules=on-demand >../actual.out 2>../actual.err &&
git config --unset fetch.recurseSubmodules
) &&
test_must_be_empty actual.out &&
test_must_be_empty actual.err
'
test_expect_success "'--recurse-submodules=on-demand' recurses as deep as necessary (and ignores config)" '
head1=$(git rev-parse --short HEAD) &&
git add submodule &&
git commit -m "new submodule" &&
head2=$(git rev-parse --short HEAD) &&
tail -3 expect.err > expect.err.deepsub &&
echo "From $pwd/." > expect.err &&
echo " $head1..$head2 super -> origin/super" >>expect.err &&
cat expect.err.sub >> expect.err &&
cat expect.err.deepsub >> expect.err &&
(
cd downstream &&
git config fetch.recurseSubmodules false &&
(
cd submodule &&
git config -f .gitmodules submodule.subdir/deepsubmodule.fetchRecursive false
) &&
git fetch --recurse-submodules=on-demand >../actual.out 2>../actual.err &&
git config --unset fetch.recurseSubmodules &&
(
cd submodule &&
git config --unset -f .gitmodules submodule.subdir/deepsubmodule.fetchRecursive
)
) &&
test_must_be_empty actual.out &&
test_cmp expect.err actual.err
'
test_expect_success "'--recurse-submodules=on-demand' stops when no new submodule commits are found in the superproject (and ignores config)" '
add_upstream_commit &&
head1=$(git rev-parse --short HEAD) &&
echo a >> file &&
git add file &&
git commit -m "new file" &&
head2=$(git rev-parse --short HEAD) &&
echo "From $pwd/." > expect.err.file &&
echo " $head1..$head2 super -> origin/super" >> expect.err.file &&
(
cd downstream &&
git fetch --recurse-submodules=on-demand >../actual.out 2>../actual.err
) &&
test_must_be_empty actual.out &&
test_cmp expect.err.file actual.err
'
test_expect_success "'fetch.recurseSubmodules=on-demand' overrides global config" '
(
cd downstream &&
git fetch --recurse-submodules
) &&
add_upstream_commit &&
git config --global fetch.recurseSubmodules false &&
head1=$(git rev-parse --short HEAD) &&
git add submodule &&
git commit -m "new submodule" &&
head2=$(git rev-parse --short HEAD) &&
echo "From $pwd/." > expect.err.2 &&
echo " $head1..$head2 super -> origin/super" >>expect.err.2 &&
head -3 expect.err >> expect.err.2 &&
(
cd downstream &&
git config fetch.recurseSubmodules on-demand &&
git fetch >../actual.out 2>../actual.err
) &&
git config --global --unset fetch.recurseSubmodules &&
(
cd downstream &&
git config --unset fetch.recurseSubmodules
) &&
test_must_be_empty actual.out &&
test_cmp expect.err.2 actual.err
'
test_expect_success "'submodule.<sub>.fetchRecurseSubmodules=on-demand' overrides fetch.recurseSubmodules" '
(
cd downstream &&
git fetch --recurse-submodules
) &&
add_upstream_commit &&
git config fetch.recurseSubmodules false &&
head1=$(git rev-parse --short HEAD) &&
git add submodule &&
git commit -m "new submodule" &&
head2=$(git rev-parse --short HEAD) &&
echo "From $pwd/." > expect.err.2 &&
echo " $head1..$head2 super -> origin/super" >>expect.err.2 &&
head -3 expect.err >> expect.err.2 &&
(
cd downstream &&
git config submodule.submodule.fetchRecurseSubmodules on-demand &&
git fetch >../actual.out 2>../actual.err
) &&
git config --unset fetch.recurseSubmodules &&
(
cd downstream &&
git config --unset submodule.submodule.fetchRecurseSubmodules
) &&
test_must_be_empty actual.out &&
test_cmp expect.err.2 actual.err
'
test_expect_success "don't fetch submodule when newly recorded commits are already present" '
(
cd submodule &&
git checkout -q HEAD^^
) &&
head1=$(git rev-parse --short HEAD) &&
git add submodule &&
git commit -m "submodule rewound" &&
head2=$(git rev-parse --short HEAD) &&
echo "From $pwd/." > expect.err &&
echo " $head1..$head2 super -> origin/super" >> expect.err &&
(
cd downstream &&
git fetch >../actual.out 2>../actual.err
) &&
test_must_be_empty actual.out &&
test_cmp expect.err actual.err &&
(
cd submodule &&
git checkout -q sub
)
'
test_expect_success "'fetch.recurseSubmodules=on-demand' works also without .gitmodules entry" '
(
cd downstream &&
git fetch --recurse-submodules
) &&
add_upstream_commit &&
head1=$(git rev-parse --short HEAD) &&
git add submodule &&
git rm .gitmodules &&
git commit -m "new submodule without .gitmodules" &&
head2=$(git rev-parse --short HEAD) &&
echo "From $pwd/." >expect.err.2 &&
echo " $head1..$head2 super -> origin/super" >>expect.err.2 &&
head -3 expect.err >>expect.err.2 &&
(
cd downstream &&
rm .gitmodules &&
git config fetch.recurseSubmodules on-demand &&
# fake submodule configuration to avoid skipping submodule handling
git config -f .gitmodules submodule.fake.path fake &&
git config -f .gitmodules submodule.fake.url fakeurl &&
git add .gitmodules &&
git config --unset submodule.submodule.url &&
git fetch >../actual.out 2>../actual.err &&
# cleanup
git config --unset fetch.recurseSubmodules &&
git reset --hard
) &&
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 23:57:25 +02:00
test_must_be_empty actual.out &&
test_cmp expect.err.2 actual.err &&
git checkout HEAD^ -- .gitmodules &&
git add .gitmodules &&
git commit -m "new submodule restored .gitmodules"
'
test_expect_success 'fetching submodules respects parallel settings' '
git config fetch.recurseSubmodules true &&
(
cd downstream &&
GIT_TRACE=$(pwd)/trace.out git fetch &&
grep "1 tasks" trace.out &&
GIT_TRACE=$(pwd)/trace.out git fetch --jobs 7 &&
grep "7 tasks" trace.out &&
git config submodule.fetchJobs 8 &&
GIT_TRACE=$(pwd)/trace.out git fetch &&
grep "8 tasks" trace.out &&
GIT_TRACE=$(pwd)/trace.out git fetch --jobs 9 &&
grep "9 tasks" trace.out
)
'
test_expect_success 'fetching submodule into a broken repository' '
# Prepare src and src/sub nested in it
git init src &&
(
cd src &&
git init sub &&
git -C sub commit --allow-empty -m "initial in sub" &&
git submodule add -- ./sub sub &&
git commit -m "initial in top"
) &&
# Clone the old-fashoned way
git clone src dst &&
git -C dst clone ../src/sub sub &&
# Make sure that old-fashoned layout is still supported
git -C dst status &&
# "diff" would find no change
git -C dst diff --exit-code &&
# Recursive-fetch works fine
git -C dst fetch --recurse-submodules &&
# Break the receiving submodule
rm -f dst/sub/.git/HEAD &&
# NOTE: without the fix the following tests will recurse forever!
# They should terminate with an error.
test_must_fail git -C dst status &&
test_must_fail git -C dst diff &&
test_must_fail git -C dst fetch --recurse-submodules
'
test_expect_success "fetch new commits when submodule got renamed" '
git clone . downstream_rename &&
(
cd downstream_rename &&
git submodule update --init --recursive &&
git checkout -b rename &&
git mv submodule submodule_renamed &&
(
cd submodule_renamed &&
git checkout -b rename_sub &&
echo a >a &&
git add a &&
git commit -ma &&
git push origin rename_sub &&
git rev-parse HEAD >../../expect
) &&
git add submodule_renamed &&
git commit -m "update renamed submodule" &&
git push origin rename
) &&
(
cd downstream &&
git fetch --recurse-submodules=on-demand &&
(
cd submodule &&
git rev-parse origin/rename_sub >../../actual
)
) &&
test_cmp expect actual
'
test_expect_success "fetch new submodule commits on-demand outside standard refspec" '
# add a second submodule and ensure it is around in downstream first
git clone submodule sub1 &&
git submodule add ./sub1 &&
git commit -m "adding a second submodule" &&
git -C downstream pull &&
git -C downstream submodule update --init --recursive &&
git checkout --detach &&
C=$(git -C submodule commit-tree -m "new change outside refs/heads" HEAD^{tree}) &&
git -C submodule update-ref refs/changes/1 $C &&
git update-index --cacheinfo 160000 $C submodule &&
test_tick &&
D=$(git -C sub1 commit-tree -m "new change outside refs/heads" HEAD^{tree}) &&
git -C sub1 update-ref refs/changes/2 $D &&
git update-index --cacheinfo 160000 $D sub1 &&
git commit -m "updated submodules outside of refs/heads" &&
E=$(git rev-parse HEAD) &&
git update-ref refs/changes/3 $E &&
(
cd downstream &&
git fetch --recurse-submodules origin refs/changes/3:refs/heads/my_branch &&
git -C submodule cat-file -t $C &&
git -C sub1 cat-file -t $D &&
git checkout --recurse-submodules FETCH_HEAD
)
'
test_expect_success 'fetch new submodule commit on-demand in FETCH_HEAD' '
# depends on the previous test for setup
C=$(git -C submodule commit-tree -m "another change outside refs/heads" HEAD^{tree}) &&
git -C submodule update-ref refs/changes/4 $C &&
git update-index --cacheinfo 160000 $C submodule &&
test_tick &&
D=$(git -C sub1 commit-tree -m "another change outside refs/heads" HEAD^{tree}) &&
git -C sub1 update-ref refs/changes/5 $D &&
git update-index --cacheinfo 160000 $D sub1 &&
git commit -m "updated submodules outside of refs/heads" &&
E=$(git rev-parse HEAD) &&
git update-ref refs/changes/6 $E &&
(
cd downstream &&
git fetch --recurse-submodules origin refs/changes/6 &&
git -C submodule cat-file -t $C &&
git -C sub1 cat-file -t $D &&
git checkout --recurse-submodules FETCH_HEAD
)
'
test_expect_success 'fetch new submodule commits on-demand without .gitmodules entry' '
# depends on the previous test for setup
git config -f .gitmodules --remove-section submodule.sub1 &&
git add .gitmodules &&
git commit -m "delete gitmodules file" &&
git checkout -B super &&
git -C downstream fetch &&
git -C downstream checkout origin/super &&
C=$(git -C submodule commit-tree -m "yet another change outside refs/heads" HEAD^{tree}) &&
git -C submodule update-ref refs/changes/7 $C &&
git update-index --cacheinfo 160000 $C submodule &&
test_tick &&
D=$(git -C sub1 commit-tree -m "yet another change outside refs/heads" HEAD^{tree}) &&
git -C sub1 update-ref refs/changes/8 $D &&
git update-index --cacheinfo 160000 $D sub1 &&
git commit -m "updated submodules outside of refs/heads" &&
E=$(git rev-parse HEAD) &&
git update-ref refs/changes/9 $E &&
(
cd downstream &&
git fetch --recurse-submodules origin refs/changes/9 &&
git -C submodule cat-file -t $C &&
git -C sub1 cat-file -t $D &&
git checkout --recurse-submodules FETCH_HEAD
)
'
test_expect_success 'fetch new submodule commit intermittently referenced by superproject' '
# depends on the previous test for setup
D=$(git -C sub1 commit-tree -m "change 10 outside refs/heads" HEAD^{tree}) &&
E=$(git -C sub1 commit-tree -m "change 11 outside refs/heads" HEAD^{tree}) &&
F=$(git -C sub1 commit-tree -m "change 12 outside refs/heads" HEAD^{tree}) &&
git -C sub1 update-ref refs/changes/10 $D &&
git update-index --cacheinfo 160000 $D sub1 &&
git commit -m "updated submodules outside of refs/heads" &&
git -C sub1 update-ref refs/changes/11 $E &&
git update-index --cacheinfo 160000 $E sub1 &&
git commit -m "updated submodules outside of refs/heads" &&
git -C sub1 update-ref refs/changes/12 $F &&
git update-index --cacheinfo 160000 $F sub1 &&
git commit -m "updated submodules outside of refs/heads" &&
G=$(git rev-parse HEAD) &&
git update-ref refs/changes/13 $G &&
(
cd downstream &&
git fetch --recurse-submodules origin refs/changes/13 &&
git -C sub1 cat-file -t $D &&
git -C sub1 cat-file -t $E &&
git -C sub1 cat-file -t $F
)
'
submodules: fix of regression on fetching of non-init subsub-repo A regression has been introduced by a62387b (submodule.c: fetch in submodules git directory instead of in worktree, 2018-11-28). The scenario in which it triggers is when one has a repository with a submodule inside a submodule like this: superproject/middle_repo/inner_repo Person A and B have both a clone of it, while Person B is not working with the inner_repo and thus does not have it initialized in his working copy. Now person A introduces a change to the inner_repo and propagates it through the middle_repo and the superproject. Once person A pushed the changes and person B wants to fetch them using "git fetch" at the superproject level, B's git call will return with error saying: Could not access submodule 'inner_repo' Errors during submodule fetch: middle_repo Expectation is that in this case the inner submodule will be recognized as uninitialized submodule and skipped by the git fetch command. This used to work correctly before 'a62387b (submodule.c: fetch in submodules git directory instead of in worktree, 2018-11-28)'. Starting with a62387b the code wants to evaluate "is_empty_dir()" inside .git/modules for a directory only existing in the worktree, delivering then of course wrong return value. This patch ensures is_empty_dir() is getting the correct path of the uninitialized submodule by concatenation of the actual worktree and the name of the uninitialized submodule. The first attempt to fix this regression, in 1b7ac4e6d4 (submodules: fix of regression on fetching of non-init subsub-repo, 2020-11-12), by simply reverting a62387b, resulted in an infinite loop of submodule fetches in the simpler case of a recursive fetch of a superproject with uninitialized submodules, and so this commit was reverted in 7091499bc0 (Revert "submodules: fix of regression on fetching of non-init subsub-repo", 2020-12-02). To prevent future breakages, also add a regression test for this scenario. Signed-off-by: Peter Kaestle <peter.kaestle@nokia.com> CC: Junio C Hamano <gitster@pobox.com> CC: Philippe Blain <levraiphilippeblain@gmail.com> CC: Ralf Thielow <ralf.thielow@gmail.com> CC: Eric Sunshine <sunshine@sunshineco.us> Reviewed-by: Philippe Blain <levraiphilippeblain@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-12-09 11:58:44 +01:00
add_commit_push () {
dir="$1" &&
msg="$2" &&
shift 2 &&
git -C "$dir" add "$@" &&
git -C "$dir" commit -a -m "$msg" &&
git -C "$dir" push
}
compare_refs_in_dir () {
fail= &&
if test "x$1" = 'x!'
then
fail='!' &&
shift
fi &&
git -C "$1" rev-parse --verify "$2" >expect &&
git -C "$3" rev-parse --verify "$4" >actual &&
eval $fail test_cmp expect actual
}
test_expect_success 'setup nested submodule fetch test' '
# does not depend on any previous test setups
for repo in outer middle inner
do
git init --bare $repo &&
git clone $repo ${repo}_content &&
echo "$repo" >"${repo}_content/file" &&
add_commit_push ${repo}_content "initial" file ||
return 1
done &&
git clone outer A &&
git -C A submodule add "$pwd/middle" &&
git -C A/middle/ submodule add "$pwd/inner" &&
add_commit_push A/middle/ "adding inner sub" .gitmodules inner &&
add_commit_push A/ "adding middle sub" .gitmodules middle &&
git clone outer B &&
git -C B/ submodule update --init middle &&
compare_refs_in_dir A HEAD B HEAD &&
compare_refs_in_dir A/middle HEAD B/middle HEAD &&
test_path_is_file B/file &&
test_path_is_file B/middle/file &&
test_path_is_missing B/middle/inner/file &&
echo "change on inner repo of A" >"A/middle/inner/file" &&
add_commit_push A/middle/inner "change on inner" file &&
add_commit_push A/middle "change on inner" inner &&
add_commit_push A "change on inner" middle
'
test_expect_success 'fetching a superproject containing an uninitialized sub/sub project' '
# depends on previous test for setup
git -C B/ fetch &&
compare_refs_in_dir A origin/HEAD B origin/HEAD
'
fetch_with_recursion_abort () {
# In a regression the following git call will run into infinite recursion.
# To handle that, we connect the sed command to the git call by a pipe
# so that sed can kill the infinite recursion when detected.
# The recursion creates git output like:
# Fetching submodule sub
# Fetching submodule sub/sub <-- [1]
# Fetching submodule sub/sub/sub
# ...
# [1] sed will stop reading and cause git to eventually stop and die
git -C "$1" fetch --recurse-submodules 2>&1 |
sed "/Fetching submodule $2[^$]/q" >out &&
! grep "Fetching submodule $2[^$]" out
}
test_expect_success 'setup recursive fetch with uninit submodule' '
# does not depend on any previous test setups
test_create_repo super &&
test_commit -C super initial &&
test_create_repo sub &&
test_commit -C sub initial &&
git -C sub rev-parse HEAD >expect &&
git -C super submodule add ../sub &&
git -C super commit -m "add sub" &&
git clone super superclone &&
git -C superclone submodule status >out &&
sed -e "s/^-//" -e "s/ sub.*$//" out >actual &&
test_cmp expect actual
'
test_expect_success 'recursive fetch with uninit submodule' '
# depends on previous test for setup
fetch_with_recursion_abort superclone sub &&
git -C superclone submodule status >out &&
sed -e "s/^-//" -e "s/ sub$//" out >actual &&
test_cmp expect actual
'
test_expect_success 'recursive fetch after deinit a submodule' '
# depends on previous test for setup
git -C superclone submodule update --init sub &&
git -C superclone submodule deinit -f sub &&
fetch_with_recursion_abort superclone sub &&
git -C superclone submodule status >out &&
sed -e "s/^-//" -e "s/ sub$//" out >actual &&
test_cmp expect actual
'
test_done