git/t/t7406-submodule-update.sh

1183 строки
32 KiB
Bash
Исходник Обычный вид История

#!/bin/sh
#
# Copyright (c) 2009 Red Hat, Inc.
#
test_description='Test updating submodules
This test verifies that "git submodule update" detaches the HEAD of the
submodule and "git submodule update --rebase/--merge" does not detach the HEAD.
'
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-19 02:44:19 +03:00
export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME
. ./test-lib.sh
compare_head()
{
sha_main=$(git rev-list --max-count=1 main)
sha_head=$(git rev-list --max-count=1 HEAD)
test "$sha_main" = "$sha_head"
}
test_expect_success 'setup a submodule tree' '
git config --global protocol.file.allow always &&
echo file > file &&
git add file &&
test_tick &&
git commit -m upstream &&
git clone . super &&
git clone super submodule &&
git clone super rebasing &&
git clone super merging &&
git clone super none &&
(cd super &&
git submodule add ../submodule submodule &&
test_tick &&
git commit -m "submodule" &&
git submodule init submodule
) &&
(cd submodule &&
echo "line2" > file &&
git add file &&
git commit -m "Commit 2"
) &&
(cd super &&
(cd submodule &&
git pull --rebase origin
) &&
git add submodule &&
git commit -m "submodule update"
) &&
(cd super &&
git submodule add ../rebasing rebasing &&
test_tick &&
git commit -m "rebasing"
) &&
(cd super &&
git submodule add ../merging merging &&
test_tick &&
git commit -m "rebasing"
) &&
(cd super &&
git submodule add ../none none &&
test_tick &&
git commit -m "none"
) &&
git clone . recursivesuper &&
( cd recursivesuper &&
git submodule add ../super super
)
'
test_expect_success 'update --remote falls back to using HEAD' '
test_create_repo main-branch-submodule &&
test_commit -C main-branch-submodule initial &&
test_create_repo main-branch &&
git -C main-branch submodule add ../main-branch-submodule &&
git -C main-branch commit -m add-submodule &&
git -C main-branch-submodule switch -c hello &&
test_commit -C main-branch-submodule world &&
git clone --recursive main-branch main-branch-clone &&
git -C main-branch-clone submodule update --remote main-branch-submodule &&
test_path_exists main-branch-clone/main-branch-submodule/world.t
'
test_expect_success 'submodule update detaching the HEAD ' '
(cd super/submodule &&
git reset --hard HEAD~1
) &&
(cd super &&
(cd submodule &&
compare_head
) &&
git submodule update submodule &&
cd submodule &&
! compare_head
)
'
test_expect_success 'submodule update from subdirectory' '
(cd super/submodule &&
git reset --hard HEAD~1
) &&
mkdir super/sub &&
(cd super/sub &&
(cd ../submodule &&
compare_head
) &&
git submodule update ../submodule &&
cd ../submodule &&
! compare_head
)
'
supersha1=$(git -C super rev-parse HEAD)
mergingsha1=$(git -C super/merging rev-parse HEAD)
nonesha1=$(git -C super/none rev-parse HEAD)
rebasingsha1=$(git -C super/rebasing rev-parse HEAD)
submodulesha1=$(git -C super/submodule rev-parse HEAD)
pwd=$(pwd)
cat <<EOF >expect
Submodule path '../super': checked out '$supersha1'
Submodule path '../super/merging': checked out '$mergingsha1'
Submodule path '../super/none': checked out '$nonesha1'
Submodule path '../super/rebasing': checked out '$rebasingsha1'
Submodule path '../super/submodule': checked out '$submodulesha1'
EOF
cat <<EOF >expect2
t7406: avoid failures solely due to timing issues Regression tests are automated tests which try to ensure a specific behavior. The idea is: if the test case fails, the behavior indicated in the test case's title regressed. If a regression test that fails, even occasionally, for any reason other than to indicate the particular regression(s) it tries to catch, it is less useful than when it really only fails when there is a bug in the (non-test) code that needs to be fixed. In the instance of the test case "submodule update --init --recursive from subdirectory" of the script t7406-submodule-update.sh, the exact output of a recursive clone is compared with a pre-generated one. And this is a racy test because the structure of the submodules only guarantees a *partial* order. The 'none' and the 'rebasing' submodules *can* be cloned in any order, which means that a mismatch with the hard-coded order does not necessarily indicate a bug in the tested code. See for example: https://git-for-windows.visualstudio.com/git/_build/results?buildId=14035&view=logs To prevent such false positives from unnecessarily costing time when investigating test failures, let's take the exact order of the lines out of the equation by sorting them before comparing them. This test script seems not to have any more test cases that try to verify any specific order in which recursive clones process the submodules, therefore this is the only test case that is changed in this manner. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-23 16:39:42 +03:00
Cloning into '$pwd/recursivesuper/super/merging'...
Cloning into '$pwd/recursivesuper/super/none'...
Cloning into '$pwd/recursivesuper/super/rebasing'...
Cloning into '$pwd/recursivesuper/super/submodule'...
Submodule 'merging' ($pwd/merging) registered for path '../super/merging'
Submodule 'none' ($pwd/none) registered for path '../super/none'
Submodule 'rebasing' ($pwd/rebasing) registered for path '../super/rebasing'
Submodule 'submodule' ($pwd/submodule) registered for path '../super/submodule'
done.
done.
done.
done.
EOF
test_expect_success 'submodule update --init --recursive from subdirectory' '
git -C recursivesuper/super reset --hard HEAD^ &&
(cd recursivesuper &&
mkdir tmp &&
cd tmp &&
git submodule update --init --recursive ../super >../../actual 2>../../actual2
) &&
test_cmp expect actual &&
t7406: avoid failures solely due to timing issues Regression tests are automated tests which try to ensure a specific behavior. The idea is: if the test case fails, the behavior indicated in the test case's title regressed. If a regression test that fails, even occasionally, for any reason other than to indicate the particular regression(s) it tries to catch, it is less useful than when it really only fails when there is a bug in the (non-test) code that needs to be fixed. In the instance of the test case "submodule update --init --recursive from subdirectory" of the script t7406-submodule-update.sh, the exact output of a recursive clone is compared with a pre-generated one. And this is a racy test because the structure of the submodules only guarantees a *partial* order. The 'none' and the 'rebasing' submodules *can* be cloned in any order, which means that a mismatch with the hard-coded order does not necessarily indicate a bug in the tested code. See for example: https://git-for-windows.visualstudio.com/git/_build/results?buildId=14035&view=logs To prevent such false positives from unnecessarily costing time when investigating test failures, let's take the exact order of the lines out of the equation by sorting them before comparing them. This test script seems not to have any more test cases that try to verify any specific order in which recursive clones process the submodules, therefore this is the only test case that is changed in this manner. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-23 16:39:42 +03:00
sort actual2 >actual2.sorted &&
test_cmp expect2 actual2.sorted
'
cat <<EOF >expect2
Submodule 'foo/sub' ($pwd/withsubs/../rebasing) registered for path 'sub'
EOF
test_expect_success 'submodule update --init from and of subdirectory' '
git init withsubs &&
(cd withsubs &&
mkdir foo &&
git submodule add "$(pwd)/../rebasing" foo/sub &&
(cd foo &&
git submodule deinit -f sub &&
git submodule update --init sub 2>../../actual2
)
) &&
test_cmp expect2 actual2
'
test_expect_success 'submodule update does not fetch already present commits' '
(cd submodule &&
echo line3 >> file &&
git add file &&
test_tick &&
git commit -m "upstream line3"
) &&
(cd super/submodule &&
head=$(git rev-parse --verify HEAD) &&
echo "Submodule path ${SQ}submodule$SQ: checked out $SQ$head$SQ" > ../../expected &&
git reset --hard HEAD~1
) &&
(cd super &&
git submodule update > ../actual 2> ../actual.err
) &&
test_cmp expected actual &&
test_must_be_empty actual.err
'
test_expect_success 'submodule update should fail due to local changes' '
(cd super/submodule &&
git reset --hard HEAD~1 &&
echo "local change" > file
) &&
(cd super &&
(cd submodule &&
compare_head
) &&
test_must_fail git submodule update submodule 2>../actual.raw
) &&
sed "s/^> //" >expect <<-\EOF &&
> error: Your local changes to the following files would be overwritten by checkout:
> file
> Please commit your changes or stash them before you switch branches.
> Aborting
> fatal: Unable to checkout OID in submodule path '\''submodule'\''
EOF
sed -e "s/checkout $SQ[^$SQ]*$SQ/checkout OID/" <actual.raw >actual &&
test_cmp expect actual
'
test_expect_success 'submodule update should throw away changes with --force ' '
(cd super &&
(cd submodule &&
compare_head
) &&
git submodule update --force submodule &&
cd submodule &&
! compare_head
)
'
test_expect_success 'submodule update --force forcibly checks out submodules' '
(cd super &&
(cd submodule &&
rm -f file
) &&
git submodule update --force submodule &&
(cd submodule &&
test "$(git status -s file)" = ""
)
)
'
submodule update: add --remote for submodule's upstream changes The current `update` command incorporates the superproject's gitlinked SHA-1 ($sha1) into the submodule HEAD ($subsha1). Depending on the options you use, it may checkout $sha1, rebase the $subsha1 onto $sha1, or merge $sha1 into $subsha1. This helps you keep up with changes in the upstream superproject. However, it's also useful to stay up to date with changes in the upstream subproject. Previous workflows for incorporating such changes include the ungainly: $ git submodule foreach 'git checkout $(git config --file $toplevel/.gitmodules submodule.$name.branch) && git pull' With this patch, all of the useful functionality for incorporating superproject changes can be reused to incorporate upstream subproject updates. When you specify --remote, the target $sha1 is replaced with a $sha1 of the submodule's origin/master tracking branch. If you want to merge a different tracking branch, you can configure the `submodule.<name>.branch` option in `.gitmodules`. You can override the `.gitmodules` configuration setting for a particular superproject by configuring the option in that superproject's default configuration (using the usual configuration hierarchy, e.g. `.git/config`, `~/.gitconfig`, etc.). Previous use of submodule.<name>.branch ======================================= Because we're adding a new configuration option, it's a good idea to check if anyone else is already using the option. The foreach-pull example above was described by Ævar in commit f030c96d8643fa0a1a9b2bd9c2f36a77721fb61f Author: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Date: Fri May 21 16:10:10 2010 +0000 git-submodule foreach: Add $toplevel variable Gerrit uses the same interpretation for the setting, but because Gerrit has direct access to the subproject repositories, it updates the superproject repositories automatically when a subproject changes. Gerrit also accepts the special value '.', which it expands into the superproject's branch name. Although the --remote functionality is using `submodule.<name>.branch` slightly differently, the effect is the same. The foreach-pull example uses the option to record the name of the local branch to checkout before pulls. The tracking branch to be pulled is recorded in `.git/modules/<name>/config`, which was initialized by the module clone during `submodule add` or `submodule init`. Because the branch name stored in `submodule.<name>.branch` was likely the same as the branch name used during the initial `submodule add`, the same branch will be pulled in each workflow. Implementation details ====================== In order to ensure a current tracking branch state, `update --remote` fetches the submodule's remote repository before calculating the SHA-1. However, I didn't change the logic guarding the existing fetch: if test -z "$nofetch" then # Run fetch only if $sha1 isn't present or it # is not reachable from a ref. (clear_local_git_env; cd "$path" && ( (rev=$(git rev-list -n 1 $sha1 --not --all 2>/dev/null) && test -z "$rev") || git-fetch)) || die "$(eval_gettext "Unable to fetch in submodule path '\$path'")" fi There will not be a double-fetch, because the new $sha1 determined after the `--remote` triggered fetch should always exist in the repository. If it doesn't, it's because some racy process removed it from the submodule's repository and we *should* be re-fetching. Signed-off-by: W. Trevor King <wking@tremily.us> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-12-19 20:03:32 +04:00
test_expect_success 'submodule update --remote should fetch upstream changes' '
(cd submodule &&
echo line4 >> file &&
git add file &&
test_tick &&
git commit -m "upstream line4"
) &&
(cd super &&
git submodule update --remote --force submodule &&
cd submodule &&
test "$(git log -1 --oneline)" = "$(GIT_DIR=../../submodule/.git git log -1 --oneline)"
)
'
test_expect_success 'submodule update --remote should fetch upstream changes with .' '
(
cd super &&
git config -f .gitmodules submodule."submodule".branch "." &&
git add .gitmodules &&
git commit -m "submodules: update from the respective superproject branch"
) &&
(
cd submodule &&
echo line4a >> file &&
git add file &&
test_tick &&
git commit -m "upstream line4a" &&
git checkout -b test-branch &&
test_commit on-test-branch
) &&
(
cd super &&
git submodule update --remote --force submodule &&
git -C submodule log -1 --oneline >actual &&
git -C ../submodule log -1 --oneline main >expect &&
test_cmp expect actual &&
git checkout -b test-branch &&
git submodule update --remote --force submodule &&
git -C submodule log -1 --oneline >actual &&
git -C ../submodule log -1 --oneline test-branch >expect &&
test_cmp expect actual &&
git checkout main &&
git branch -d test-branch &&
git reset --hard HEAD^
)
'
submodule update: add --remote for submodule's upstream changes The current `update` command incorporates the superproject's gitlinked SHA-1 ($sha1) into the submodule HEAD ($subsha1). Depending on the options you use, it may checkout $sha1, rebase the $subsha1 onto $sha1, or merge $sha1 into $subsha1. This helps you keep up with changes in the upstream superproject. However, it's also useful to stay up to date with changes in the upstream subproject. Previous workflows for incorporating such changes include the ungainly: $ git submodule foreach 'git checkout $(git config --file $toplevel/.gitmodules submodule.$name.branch) && git pull' With this patch, all of the useful functionality for incorporating superproject changes can be reused to incorporate upstream subproject updates. When you specify --remote, the target $sha1 is replaced with a $sha1 of the submodule's origin/master tracking branch. If you want to merge a different tracking branch, you can configure the `submodule.<name>.branch` option in `.gitmodules`. You can override the `.gitmodules` configuration setting for a particular superproject by configuring the option in that superproject's default configuration (using the usual configuration hierarchy, e.g. `.git/config`, `~/.gitconfig`, etc.). Previous use of submodule.<name>.branch ======================================= Because we're adding a new configuration option, it's a good idea to check if anyone else is already using the option. The foreach-pull example above was described by Ævar in commit f030c96d8643fa0a1a9b2bd9c2f36a77721fb61f Author: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Date: Fri May 21 16:10:10 2010 +0000 git-submodule foreach: Add $toplevel variable Gerrit uses the same interpretation for the setting, but because Gerrit has direct access to the subproject repositories, it updates the superproject repositories automatically when a subproject changes. Gerrit also accepts the special value '.', which it expands into the superproject's branch name. Although the --remote functionality is using `submodule.<name>.branch` slightly differently, the effect is the same. The foreach-pull example uses the option to record the name of the local branch to checkout before pulls. The tracking branch to be pulled is recorded in `.git/modules/<name>/config`, which was initialized by the module clone during `submodule add` or `submodule init`. Because the branch name stored in `submodule.<name>.branch` was likely the same as the branch name used during the initial `submodule add`, the same branch will be pulled in each workflow. Implementation details ====================== In order to ensure a current tracking branch state, `update --remote` fetches the submodule's remote repository before calculating the SHA-1. However, I didn't change the logic guarding the existing fetch: if test -z "$nofetch" then # Run fetch only if $sha1 isn't present or it # is not reachable from a ref. (clear_local_git_env; cd "$path" && ( (rev=$(git rev-list -n 1 $sha1 --not --all 2>/dev/null) && test -z "$rev") || git-fetch)) || die "$(eval_gettext "Unable to fetch in submodule path '\$path'")" fi There will not be a double-fetch, because the new $sha1 determined after the `--remote` triggered fetch should always exist in the repository. If it doesn't, it's because some racy process removed it from the submodule's repository and we *should* be re-fetching. Signed-off-by: W. Trevor King <wking@tremily.us> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-12-19 20:03:32 +04:00
test_expect_success 'local config should override .gitmodules branch' '
(cd submodule &&
git checkout test-branch &&
submodule update: add --remote for submodule's upstream changes The current `update` command incorporates the superproject's gitlinked SHA-1 ($sha1) into the submodule HEAD ($subsha1). Depending on the options you use, it may checkout $sha1, rebase the $subsha1 onto $sha1, or merge $sha1 into $subsha1. This helps you keep up with changes in the upstream superproject. However, it's also useful to stay up to date with changes in the upstream subproject. Previous workflows for incorporating such changes include the ungainly: $ git submodule foreach 'git checkout $(git config --file $toplevel/.gitmodules submodule.$name.branch) && git pull' With this patch, all of the useful functionality for incorporating superproject changes can be reused to incorporate upstream subproject updates. When you specify --remote, the target $sha1 is replaced with a $sha1 of the submodule's origin/master tracking branch. If you want to merge a different tracking branch, you can configure the `submodule.<name>.branch` option in `.gitmodules`. You can override the `.gitmodules` configuration setting for a particular superproject by configuring the option in that superproject's default configuration (using the usual configuration hierarchy, e.g. `.git/config`, `~/.gitconfig`, etc.). Previous use of submodule.<name>.branch ======================================= Because we're adding a new configuration option, it's a good idea to check if anyone else is already using the option. The foreach-pull example above was described by Ævar in commit f030c96d8643fa0a1a9b2bd9c2f36a77721fb61f Author: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Date: Fri May 21 16:10:10 2010 +0000 git-submodule foreach: Add $toplevel variable Gerrit uses the same interpretation for the setting, but because Gerrit has direct access to the subproject repositories, it updates the superproject repositories automatically when a subproject changes. Gerrit also accepts the special value '.', which it expands into the superproject's branch name. Although the --remote functionality is using `submodule.<name>.branch` slightly differently, the effect is the same. The foreach-pull example uses the option to record the name of the local branch to checkout before pulls. The tracking branch to be pulled is recorded in `.git/modules/<name>/config`, which was initialized by the module clone during `submodule add` or `submodule init`. Because the branch name stored in `submodule.<name>.branch` was likely the same as the branch name used during the initial `submodule add`, the same branch will be pulled in each workflow. Implementation details ====================== In order to ensure a current tracking branch state, `update --remote` fetches the submodule's remote repository before calculating the SHA-1. However, I didn't change the logic guarding the existing fetch: if test -z "$nofetch" then # Run fetch only if $sha1 isn't present or it # is not reachable from a ref. (clear_local_git_env; cd "$path" && ( (rev=$(git rev-list -n 1 $sha1 --not --all 2>/dev/null) && test -z "$rev") || git-fetch)) || die "$(eval_gettext "Unable to fetch in submodule path '\$path'")" fi There will not be a double-fetch, because the new $sha1 determined after the `--remote` triggered fetch should always exist in the repository. If it doesn't, it's because some racy process removed it from the submodule's repository and we *should* be re-fetching. Signed-off-by: W. Trevor King <wking@tremily.us> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-12-19 20:03:32 +04:00
echo line5 >> file &&
git add file &&
test_tick &&
git commit -m "upstream line5" &&
git checkout main
submodule update: add --remote for submodule's upstream changes The current `update` command incorporates the superproject's gitlinked SHA-1 ($sha1) into the submodule HEAD ($subsha1). Depending on the options you use, it may checkout $sha1, rebase the $subsha1 onto $sha1, or merge $sha1 into $subsha1. This helps you keep up with changes in the upstream superproject. However, it's also useful to stay up to date with changes in the upstream subproject. Previous workflows for incorporating such changes include the ungainly: $ git submodule foreach 'git checkout $(git config --file $toplevel/.gitmodules submodule.$name.branch) && git pull' With this patch, all of the useful functionality for incorporating superproject changes can be reused to incorporate upstream subproject updates. When you specify --remote, the target $sha1 is replaced with a $sha1 of the submodule's origin/master tracking branch. If you want to merge a different tracking branch, you can configure the `submodule.<name>.branch` option in `.gitmodules`. You can override the `.gitmodules` configuration setting for a particular superproject by configuring the option in that superproject's default configuration (using the usual configuration hierarchy, e.g. `.git/config`, `~/.gitconfig`, etc.). Previous use of submodule.<name>.branch ======================================= Because we're adding a new configuration option, it's a good idea to check if anyone else is already using the option. The foreach-pull example above was described by Ævar in commit f030c96d8643fa0a1a9b2bd9c2f36a77721fb61f Author: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Date: Fri May 21 16:10:10 2010 +0000 git-submodule foreach: Add $toplevel variable Gerrit uses the same interpretation for the setting, but because Gerrit has direct access to the subproject repositories, it updates the superproject repositories automatically when a subproject changes. Gerrit also accepts the special value '.', which it expands into the superproject's branch name. Although the --remote functionality is using `submodule.<name>.branch` slightly differently, the effect is the same. The foreach-pull example uses the option to record the name of the local branch to checkout before pulls. The tracking branch to be pulled is recorded in `.git/modules/<name>/config`, which was initialized by the module clone during `submodule add` or `submodule init`. Because the branch name stored in `submodule.<name>.branch` was likely the same as the branch name used during the initial `submodule add`, the same branch will be pulled in each workflow. Implementation details ====================== In order to ensure a current tracking branch state, `update --remote` fetches the submodule's remote repository before calculating the SHA-1. However, I didn't change the logic guarding the existing fetch: if test -z "$nofetch" then # Run fetch only if $sha1 isn't present or it # is not reachable from a ref. (clear_local_git_env; cd "$path" && ( (rev=$(git rev-list -n 1 $sha1 --not --all 2>/dev/null) && test -z "$rev") || git-fetch)) || die "$(eval_gettext "Unable to fetch in submodule path '\$path'")" fi There will not be a double-fetch, because the new $sha1 determined after the `--remote` triggered fetch should always exist in the repository. If it doesn't, it's because some racy process removed it from the submodule's repository and we *should* be re-fetching. Signed-off-by: W. Trevor King <wking@tremily.us> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-12-19 20:03:32 +04:00
) &&
(cd super &&
git config submodule.submodule.branch test-branch &&
git submodule update --remote --force submodule &&
cd submodule &&
test "$(git log -1 --oneline)" = "$(GIT_DIR=../../submodule/.git git log -1 --oneline test-branch)"
)
'
test_expect_success 'submodule update --rebase staying on main' '
(cd super/submodule &&
git checkout main
) &&
(cd super &&
(cd submodule &&
compare_head
) &&
git submodule update --rebase submodule &&
cd submodule &&
compare_head
)
'
test_expect_success 'submodule update --merge staying on main' '
(cd super/submodule &&
git reset --hard HEAD~1
) &&
(cd super &&
(cd submodule &&
compare_head
) &&
git submodule update --merge submodule &&
cd submodule &&
compare_head
)
'
test_expect_success 'submodule update - rebase in .git/config' '
(cd super &&
git config submodule.submodule.update rebase
) &&
(cd super/submodule &&
git reset --hard HEAD~1
) &&
(cd super &&
(cd submodule &&
compare_head
) &&
git submodule update submodule &&
cd submodule &&
compare_head
)
'
test_expect_success 'submodule update - checkout in .git/config but --rebase given' '
(cd super &&
git config submodule.submodule.update checkout
) &&
(cd super/submodule &&
git reset --hard HEAD~1
) &&
(cd super &&
(cd submodule &&
compare_head
) &&
git submodule update --rebase submodule &&
cd submodule &&
compare_head
)
'
test_expect_success 'submodule update - merge in .git/config' '
(cd super &&
git config submodule.submodule.update merge
) &&
(cd super/submodule &&
git reset --hard HEAD~1
) &&
(cd super &&
(cd submodule &&
compare_head
) &&
git submodule update submodule &&
cd submodule &&
compare_head
)
'
test_expect_success 'submodule update - checkout in .git/config but --merge given' '
(cd super &&
git config submodule.submodule.update checkout
) &&
(cd super/submodule &&
git reset --hard HEAD~1
) &&
(cd super &&
(cd submodule &&
compare_head
) &&
git submodule update --merge submodule &&
cd submodule &&
compare_head
)
'
test_expect_success 'submodule update - checkout in .git/config' '
(cd super &&
git config submodule.submodule.update checkout
) &&
(cd super/submodule &&
git reset --hard HEAD^
) &&
(cd super &&
(cd submodule &&
compare_head
) &&
git submodule update submodule &&
cd submodule &&
! compare_head
)
'
test_expect_success 'submodule update - command in .git/config' '
(cd super &&
git config submodule.submodule.update "!git checkout"
) &&
(cd super/submodule &&
git reset --hard HEAD^
) &&
(cd super &&
(cd submodule &&
compare_head
) &&
git submodule update submodule &&
cd submodule &&
! compare_head
)
'
submodule: reject submodule.update = !command in .gitmodules Since ac1fbbda2013 (submodule: do not copy unknown update mode from .gitmodules, 2013-12-02), Git has been careful to avoid copying [submodule "foo"] update = !run an arbitrary scary command from .gitmodules to a repository's local config, copying in the setting 'update = none' instead. The gitmodules(5) manpage documents the intention: The !command form is intentionally ignored here for security reasons Unfortunately, starting with v2.20.0-rc0 (which integrated ee69b2a9 (submodule--helper: introduce new update-module-mode helper, 2018-08-13, first released in v2.20.0-rc0)), there are scenarios where we *don't* ignore it: if the config store contains no submodule.foo.update setting, the submodule-config API falls back to reading .gitmodules and the repository-supplied !command gets run after all. This was part of a general change over time in submodule support to read more directly from .gitmodules, since unlike .git/config it allows a project to change values between branches and over time (while still allowing .git/config to override things). But it was never intended to apply to this kind of dangerous configuration. The behavior change was not advertised in ee69b2a9's commit message and was missed in review. Let's take the opportunity to make the protection more robust, even in Git versions that are technically not affected: instead of quietly converting 'update = !command' to 'update = none', noisily treat it as an error. Allowing the setting but treating it as meaning something else was just confusing; users are better served by seeing the error sooner. Forbidding the construct makes the semantics simpler and means we can check for it in fsck (in a separate patch). As a result, the submodule-config API cannot read this value from .gitmodules under any circumstance, and we can declare with confidence For security reasons, the '!command' form is not accepted here. Reported-by: Joern Schneeweisz <jschneeweisz@gitlab.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
2019-12-05 12:28:28 +03:00
test_expect_success 'submodule update - command in .gitmodules is rejected' '
test_when_finished "git -C super reset --hard HEAD^" &&
git -C super config -f .gitmodules submodule.submodule.update "!false" &&
git -C super commit -a -m "add command to .gitmodules file" &&
git -C super/submodule reset --hard $submodulesha1^ &&
submodule: reject submodule.update = !command in .gitmodules Since ac1fbbda2013 (submodule: do not copy unknown update mode from .gitmodules, 2013-12-02), Git has been careful to avoid copying [submodule "foo"] update = !run an arbitrary scary command from .gitmodules to a repository's local config, copying in the setting 'update = none' instead. The gitmodules(5) manpage documents the intention: The !command form is intentionally ignored here for security reasons Unfortunately, starting with v2.20.0-rc0 (which integrated ee69b2a9 (submodule--helper: introduce new update-module-mode helper, 2018-08-13, first released in v2.20.0-rc0)), there are scenarios where we *don't* ignore it: if the config store contains no submodule.foo.update setting, the submodule-config API falls back to reading .gitmodules and the repository-supplied !command gets run after all. This was part of a general change over time in submodule support to read more directly from .gitmodules, since unlike .git/config it allows a project to change values between branches and over time (while still allowing .git/config to override things). But it was never intended to apply to this kind of dangerous configuration. The behavior change was not advertised in ee69b2a9's commit message and was missed in review. Let's take the opportunity to make the protection more robust, even in Git versions that are technically not affected: instead of quietly converting 'update = !command' to 'update = none', noisily treat it as an error. Allowing the setting but treating it as meaning something else was just confusing; users are better served by seeing the error sooner. Forbidding the construct makes the semantics simpler and means we can check for it in fsck (in a separate patch). As a result, the submodule-config API cannot read this value from .gitmodules under any circumstance, and we can declare with confidence For security reasons, the '!command' form is not accepted here. Reported-by: Joern Schneeweisz <jschneeweisz@gitlab.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
2019-12-05 12:28:28 +03:00
test_must_fail git -C super submodule update submodule
'
test_expect_success 'fsck detects command in .gitmodules' '
git init command-in-gitmodules &&
(
cd command-in-gitmodules &&
git submodule add ../submodule submodule &&
test_commit adding-submodule &&
git config -f .gitmodules submodule.submodule.update "!false" &&
git add .gitmodules &&
test_commit configuring-update &&
test_must_fail git fsck
)
'
cat << EOF >expect
fatal: Execution of 'false $submodulesha1' failed in submodule path 'submodule'
EOF
test_expect_success 'submodule update - command in .git/config catches failure' '
(cd super &&
git config submodule.submodule.update "!false"
) &&
(cd super/submodule &&
git reset --hard $submodulesha1^
) &&
(cd super &&
test_must_fail git submodule update submodule 2>../actual
) &&
test_cmp actual expect
'
cat << EOF >expect
fatal: Execution of 'false $submodulesha1' failed in submodule path '../submodule'
EOF
test_expect_success 'submodule update - command in .git/config catches failure -- subdirectory' '
(cd super &&
git config submodule.submodule.update "!false"
) &&
(cd super/submodule &&
git reset --hard $submodulesha1^
) &&
(cd super &&
mkdir tmp && cd tmp &&
test_must_fail git submodule update ../submodule 2>../../actual
) &&
test_cmp actual expect
'
test_expect_success 'submodule update - command run for initial population of submodule' '
cat >expect <<-EOF &&
fatal: Execution of '\''false $submodulesha1'\'' failed in submodule path '\''submodule'\''
EOF
rm -rf super/submodule &&
test_must_fail git -C super submodule update 2>actual &&
test_cmp expect actual &&
git -C super submodule update --checkout
'
cat << EOF >expect
fatal: Execution of 'false $submodulesha1' failed in submodule path '../super/submodule'
fatal: Failed to recurse into submodule path '../super'
EOF
test_expect_success 'recursive submodule update - command in .git/config catches failure -- subdirectory' '
(cd recursivesuper &&
git submodule update --remote super &&
git add super &&
git commit -m "update to latest to have more than one commit in submodules"
) &&
git -C recursivesuper/super config submodule.submodule.update "!false" &&
git -C recursivesuper/super/submodule reset --hard $submodulesha1^ &&
(cd recursivesuper &&
mkdir -p tmp && cd tmp &&
test_must_fail git submodule update --recursive ../super 2>../../actual
) &&
test_cmp actual expect
'
test_expect_success 'submodule init does not copy command into .git/config' '
submodule: reject submodule.update = !command in .gitmodules Since ac1fbbda2013 (submodule: do not copy unknown update mode from .gitmodules, 2013-12-02), Git has been careful to avoid copying [submodule "foo"] update = !run an arbitrary scary command from .gitmodules to a repository's local config, copying in the setting 'update = none' instead. The gitmodules(5) manpage documents the intention: The !command form is intentionally ignored here for security reasons Unfortunately, starting with v2.20.0-rc0 (which integrated ee69b2a9 (submodule--helper: introduce new update-module-mode helper, 2018-08-13, first released in v2.20.0-rc0)), there are scenarios where we *don't* ignore it: if the config store contains no submodule.foo.update setting, the submodule-config API falls back to reading .gitmodules and the repository-supplied !command gets run after all. This was part of a general change over time in submodule support to read more directly from .gitmodules, since unlike .git/config it allows a project to change values between branches and over time (while still allowing .git/config to override things). But it was never intended to apply to this kind of dangerous configuration. The behavior change was not advertised in ee69b2a9's commit message and was missed in review. Let's take the opportunity to make the protection more robust, even in Git versions that are technically not affected: instead of quietly converting 'update = !command' to 'update = none', noisily treat it as an error. Allowing the setting but treating it as meaning something else was just confusing; users are better served by seeing the error sooner. Forbidding the construct makes the semantics simpler and means we can check for it in fsck (in a separate patch). As a result, the submodule-config API cannot read this value from .gitmodules under any circumstance, and we can declare with confidence For security reasons, the '!command' form is not accepted here. Reported-by: Joern Schneeweisz <jschneeweisz@gitlab.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
2019-12-05 12:28:28 +03:00
test_when_finished "git -C super update-index --force-remove submodule1" &&
test_when_finished git config -f super/.gitmodules \
--remove-section submodule.submodule1 &&
(cd super &&
git ls-files -s submodule >out &&
H=$(cut -d" " -f2 out) &&
mkdir submodule1 &&
git update-index --add --cacheinfo 160000 $H submodule1 &&
git config -f .gitmodules submodule.submodule1.path submodule1 &&
git config -f .gitmodules submodule.submodule1.url ../submodule &&
git config -f .gitmodules submodule.submodule1.update !false &&
submodule: reject submodule.update = !command in .gitmodules Since ac1fbbda2013 (submodule: do not copy unknown update mode from .gitmodules, 2013-12-02), Git has been careful to avoid copying [submodule "foo"] update = !run an arbitrary scary command from .gitmodules to a repository's local config, copying in the setting 'update = none' instead. The gitmodules(5) manpage documents the intention: The !command form is intentionally ignored here for security reasons Unfortunately, starting with v2.20.0-rc0 (which integrated ee69b2a9 (submodule--helper: introduce new update-module-mode helper, 2018-08-13, first released in v2.20.0-rc0)), there are scenarios where we *don't* ignore it: if the config store contains no submodule.foo.update setting, the submodule-config API falls back to reading .gitmodules and the repository-supplied !command gets run after all. This was part of a general change over time in submodule support to read more directly from .gitmodules, since unlike .git/config it allows a project to change values between branches and over time (while still allowing .git/config to override things). But it was never intended to apply to this kind of dangerous configuration. The behavior change was not advertised in ee69b2a9's commit message and was missed in review. Let's take the opportunity to make the protection more robust, even in Git versions that are technically not affected: instead of quietly converting 'update = !command' to 'update = none', noisily treat it as an error. Allowing the setting but treating it as meaning something else was just confusing; users are better served by seeing the error sooner. Forbidding the construct makes the semantics simpler and means we can check for it in fsck (in a separate patch). As a result, the submodule-config API cannot read this value from .gitmodules under any circumstance, and we can declare with confidence For security reasons, the '!command' form is not accepted here. Reported-by: Joern Schneeweisz <jschneeweisz@gitlab.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
2019-12-05 12:28:28 +03:00
test_must_fail git submodule init submodule1 &&
test_expect_code 1 git config submodule.submodule1.update >actual &&
test_must_be_empty actual
)
'
test_expect_success 'submodule init picks up rebase' '
(cd super &&
git config -f .gitmodules submodule.rebasing.update rebase &&
git submodule init rebasing &&
test "rebase" = "$(git config submodule.rebasing.update)"
)
'
test_expect_success 'submodule init picks up merge' '
(cd super &&
git config -f .gitmodules submodule.merging.update merge &&
git submodule init merging &&
test "merge" = "$(git config submodule.merging.update)"
)
'
test_expect_success 'submodule update --merge - ignores --merge for new submodules' '
test_config -C super submodule.submodule.update checkout &&
(cd super &&
rm -rf submodule &&
git submodule update submodule &&
git status -s submodule >expect &&
rm -rf submodule &&
git submodule update --merge submodule &&
git status -s submodule >actual &&
test_cmp expect actual
)
'
test_expect_success 'submodule update --rebase - ignores --rebase for new submodules' '
test_config -C super submodule.submodule.update checkout &&
(cd super &&
rm -rf submodule &&
git submodule update submodule &&
git status -s submodule >expect &&
rm -rf submodule &&
git submodule update --rebase submodule &&
git status -s submodule >actual &&
test_cmp expect actual
)
'
test_expect_success 'submodule update ignores update=merge config for new submodules' '
(cd super &&
rm -rf submodule &&
git submodule update submodule &&
git status -s submodule >expect &&
rm -rf submodule &&
git config submodule.submodule.update merge &&
git submodule update submodule &&
git status -s submodule >actual &&
git config --unset submodule.submodule.update &&
test_cmp expect actual
)
'
test_expect_success 'submodule update ignores update=rebase config for new submodules' '
(cd super &&
rm -rf submodule &&
git submodule update submodule &&
git status -s submodule >expect &&
rm -rf submodule &&
git config submodule.submodule.update rebase &&
git submodule update submodule &&
git status -s submodule >actual &&
git config --unset submodule.submodule.update &&
test_cmp expect actual
)
'
test_expect_success 'submodule init picks up update=none' '
(cd super &&
git config -f .gitmodules submodule.none.update none &&
git submodule init none &&
test "none" = "$(git config submodule.none.update)"
)
'
test_expect_success 'submodule update - update=none in .git/config' '
(cd super &&
git config submodule.submodule.update none &&
(cd submodule &&
git checkout main &&
compare_head
) &&
git diff --name-only >out &&
grep ^submodule$ out &&
git submodule update &&
git diff --name-only >out &&
grep ^submodule$ out &&
(cd submodule &&
compare_head
) &&
git config --unset submodule.submodule.update &&
git submodule update submodule
)
'
test_expect_success 'submodule update - update=none in .git/config but --checkout given' '
(cd super &&
git config submodule.submodule.update none &&
(cd submodule &&
git checkout main &&
compare_head
) &&
git diff --name-only >out &&
grep ^submodule$ out &&
git submodule update --checkout &&
git diff --name-only >out &&
! grep ^submodule$ out &&
(cd submodule &&
! compare_head
) &&
git config --unset submodule.submodule.update
)
'
test_expect_success 'submodule update --init skips submodule with update=none' '
(cd super &&
git add .gitmodules &&
git commit -m ".gitmodules"
) &&
git clone super cloned &&
(cd cloned &&
git submodule update --init &&
test_path_exists submodule/.git &&
test_path_is_missing none/.git
)
'
test_expect_success 'submodule update with pathspec warns against uninitialized ones' '
test_when_finished "rm -fr selective" &&
git clone super selective &&
(
cd selective &&
git submodule init submodule &&
git submodule update submodule 2>err &&
! grep "Submodule path .* not initialized" err &&
git submodule update rebasing 2>err &&
grep "Submodule path .rebasing. not initialized" err &&
test_path_exists submodule/.git &&
test_path_is_missing rebasing/.git
)
'
test_expect_success 'submodule update without pathspec updates only initialized ones' '
test_when_finished "rm -fr selective" &&
git clone super selective &&
(
cd selective &&
git submodule init submodule &&
git submodule update 2>err &&
test_path_exists submodule/.git &&
test_path_is_missing rebasing/.git &&
! grep "Submodule path .* not initialized" err
)
'
test_expect_success 'submodule update continues after checkout error' '
(cd super &&
git reset --hard HEAD &&
git submodule add ../submodule submodule2 &&
git submodule init &&
git commit -am "new_submodule" &&
(cd submodule2 &&
git rev-parse --verify HEAD >../expect
) &&
(cd submodule &&
test_commit "update_submodule" file
) &&
(cd submodule2 &&
test_commit "update_submodule2" file
) &&
git add submodule &&
git add submodule2 &&
git commit -m "two_new_submodule_commits" &&
(cd submodule &&
echo "" > file
) &&
git checkout HEAD^ &&
test_must_fail git submodule update &&
(cd submodule2 &&
git rev-parse --verify HEAD >../actual
) &&
test_cmp expect actual
)
'
test_expect_success 'submodule update continues after recursive checkout error' '
(cd super &&
git reset --hard HEAD &&
git checkout main &&
git submodule update &&
(cd submodule &&
git submodule add ../submodule subsubmodule &&
git submodule init &&
git commit -m "new_subsubmodule"
) &&
git add submodule &&
git commit -m "update_submodule" &&
(cd submodule &&
(cd subsubmodule &&
test_commit "update_subsubmodule" file
) &&
git add subsubmodule &&
test_commit "update_submodule_again" file &&
(cd subsubmodule &&
test_commit "update_subsubmodule_again" file
) &&
test_commit "update_submodule_again_again" file
) &&
(cd submodule2 &&
git rev-parse --verify HEAD >../expect &&
test_commit "update_submodule2_again" file
) &&
git add submodule &&
git add submodule2 &&
git commit -m "new_commits" &&
git checkout HEAD^ &&
(cd submodule &&
git checkout HEAD^ &&
(cd subsubmodule &&
echo "" > file
)
) &&
test_expect_code 1 git submodule update --recursive &&
(cd submodule2 &&
git rev-parse --verify HEAD >../actual
) &&
test_cmp expect actual
)
'
test_expect_success 'submodule update exit immediately in case of merge conflict' '
(cd super &&
git checkout main &&
git reset --hard HEAD &&
(cd submodule &&
(cd subsubmodule &&
git reset --hard HEAD
)
) &&
git submodule update --recursive &&
(cd submodule &&
test_commit "update_submodule_2" file
) &&
(cd submodule2 &&
test_commit "update_submodule2_2" file
) &&
git add submodule &&
git add submodule2 &&
git commit -m "two_new_submodule_commits" &&
(cd submodule &&
git checkout main &&
test_commit "conflict" file &&
echo "conflict" > file
) &&
git checkout HEAD^ &&
(cd submodule2 &&
git rev-parse --verify HEAD >../expect
) &&
git config submodule.submodule.update merge &&
test_must_fail git submodule update &&
(cd submodule2 &&
git rev-parse --verify HEAD >../actual
) &&
test_cmp expect actual
)
'
test_expect_success 'submodule update exit immediately after recursive rebase error' '
(cd super &&
git checkout main &&
git reset --hard HEAD &&
(cd submodule &&
git reset --hard HEAD &&
git submodule update --recursive
) &&
(cd submodule &&
test_commit "update_submodule_3" file
) &&
(cd submodule2 &&
test_commit "update_submodule2_3" file
) &&
git add submodule &&
git add submodule2 &&
git commit -m "two_new_submodule_commits" &&
(cd submodule &&
git checkout main &&
test_commit "conflict2" file &&
echo "conflict" > file
) &&
git checkout HEAD^ &&
(cd submodule2 &&
git rev-parse --verify HEAD >../expect
) &&
git config submodule.submodule.update rebase &&
test_must_fail git submodule update &&
(cd submodule2 &&
git rev-parse --verify HEAD >../actual
) &&
test_cmp expect actual
)
'
test_expect_success 'add different submodules to the same path' '
(cd super &&
git submodule add ../submodule s1 &&
test_must_fail git submodule add ../merging s1
)
'
test_expect_success 'submodule add places git-dir in superprojects git-dir' '
(cd super &&
mkdir deeper &&
git submodule add ../submodule deeper/submodule &&
(cd deeper/submodule &&
git log > ../../expected
) &&
(cd .git/modules/deeper/submodule &&
git log > ../../../../actual
) &&
test_cmp expected actual
)
'
test_expect_success 'submodule update places git-dir in superprojects git-dir' '
(cd super &&
git commit -m "added submodule"
) &&
git clone super super2 &&
(cd super2 &&
git submodule init deeper/submodule &&
git submodule update &&
(cd deeper/submodule &&
git log > ../../expected
) &&
(cd .git/modules/deeper/submodule &&
git log > ../../../../actual
) &&
test_cmp expected actual
)
'
test_expect_success 'submodule add places git-dir in superprojects git-dir recursive' '
(cd super2 &&
(cd deeper/submodule &&
git submodule add ../submodule subsubmodule &&
(cd subsubmodule &&
git log > ../../../expected
) &&
git commit -m "added subsubmodule" &&
git push origin :
) &&
(cd .git/modules/deeper/submodule/modules/subsubmodule &&
git log > ../../../../../actual
) &&
git add deeper/submodule &&
git commit -m "update submodule" &&
git push origin : &&
test_cmp expected actual
)
'
test_expect_success 'submodule update places git-dir in superprojects git-dir recursive' '
mkdir super_update_r &&
(cd super_update_r &&
git init --bare
) &&
mkdir subsuper_update_r &&
(cd subsuper_update_r &&
git init --bare
) &&
mkdir subsubsuper_update_r &&
(cd subsubsuper_update_r &&
git init --bare
) &&
git clone subsubsuper_update_r subsubsuper_update_r2 &&
(cd subsubsuper_update_r2 &&
test_commit "update_subsubsuper" file &&
git push origin main
) &&
git clone subsuper_update_r subsuper_update_r2 &&
(cd subsuper_update_r2 &&
test_commit "update_subsuper" file &&
git submodule add ../subsubsuper_update_r subsubmodule &&
git commit -am "subsubmodule" &&
git push origin main
) &&
git clone super_update_r super_update_r2 &&
(cd super_update_r2 &&
test_commit "update_super" file &&
git submodule add ../subsuper_update_r submodule &&
git commit -am "submodule" &&
git push origin main
) &&
rm -rf super_update_r2 &&
git clone super_update_r super_update_r2 &&
(cd super_update_r2 &&
git submodule update --init --recursive >actual &&
test_i18ngrep "Submodule path .submodule/subsubmodule.: checked out" actual &&
(cd submodule/subsubmodule &&
git log > ../../expected
) &&
(cd .git/modules/submodule/modules/subsubmodule &&
git log > ../../../../../actual
) &&
test_cmp expected actual
)
'
test_expect_success 'submodule add properly re-creates deeper level submodules' '
(cd super &&
git reset --hard main &&
rm -rf deeper/ &&
git submodule add --force ../submodule deeper/submodule
)
'
submodules: refactor computation of relative gitdir path In module_clone() the rel_gitdir variable was computed differently when "git rev-parse --git-dir" returned a relative path than when it returned an absolute path. This is not optimal, as different code paths are used depending on the return value of that command. Fix that by reusing the differing path components computed for setting the core.worktree config setting, which leaves a single code path for setting both instead of having three and makes the code much shorter. This also fixes the bug that in the computation of how many directories have to be traversed up to hit the root directory of the submodule the name of the submodule was used where the path should have been used. This lead to problems after renaming submodules into another directory level. Even though the "(cd $somewhere && pwd)" approach breaks the flexibility of symlinks, that is no issue here as we have to have one relative path pointing from the work tree to the gitdir and another pointing back, which will never work anyway when a symlink along one of those paths is changed because the directory it points to was moved. Also add a test moving a submodule into a deeper directory to catch any future breakage here and to document what has to be done when a submodule needs to be moved until git mv learns to do that. Simply moving it to the new location doesn't work, as the core.worktree and possibly the gitfile setting too will be wrong. So it has to be removed from filesystem and index, then the new location has to be added into the index and the .gitmodules file has to be updated. After that a git submodule update will check out the submodule at the new location. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-03-05 01:15:36 +04:00
test_expect_success 'submodule update properly revives a moved submodule' '
(cd super &&
H=$(git rev-parse --short HEAD) &&
submodules: refactor computation of relative gitdir path In module_clone() the rel_gitdir variable was computed differently when "git rev-parse --git-dir" returned a relative path than when it returned an absolute path. This is not optimal, as different code paths are used depending on the return value of that command. Fix that by reusing the differing path components computed for setting the core.worktree config setting, which leaves a single code path for setting both instead of having three and makes the code much shorter. This also fixes the bug that in the computation of how many directories have to be traversed up to hit the root directory of the submodule the name of the submodule was used where the path should have been used. This lead to problems after renaming submodules into another directory level. Even though the "(cd $somewhere && pwd)" approach breaks the flexibility of symlinks, that is no issue here as we have to have one relative path pointing from the work tree to the gitdir and another pointing back, which will never work anyway when a symlink along one of those paths is changed because the directory it points to was moved. Also add a test moving a submodule into a deeper directory to catch any future breakage here and to document what has to be done when a submodule needs to be moved until git mv learns to do that. Simply moving it to the new location doesn't work, as the core.worktree and possibly the gitfile setting too will be wrong. So it has to be removed from filesystem and index, then the new location has to be added into the index and the .gitmodules file has to be updated. After that a git submodule update will check out the submodule at the new location. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-03-05 01:15:36 +04:00
git commit -am "pre move" &&
H2=$(git rev-parse --short HEAD) &&
git status >out &&
sed "s/$H/XXX/" out >expect &&
H=$(cd submodule2 && git rev-parse HEAD) &&
submodules: refactor computation of relative gitdir path In module_clone() the rel_gitdir variable was computed differently when "git rev-parse --git-dir" returned a relative path than when it returned an absolute path. This is not optimal, as different code paths are used depending on the return value of that command. Fix that by reusing the differing path components computed for setting the core.worktree config setting, which leaves a single code path for setting both instead of having three and makes the code much shorter. This also fixes the bug that in the computation of how many directories have to be traversed up to hit the root directory of the submodule the name of the submodule was used where the path should have been used. This lead to problems after renaming submodules into another directory level. Even though the "(cd $somewhere && pwd)" approach breaks the flexibility of symlinks, that is no issue here as we have to have one relative path pointing from the work tree to the gitdir and another pointing back, which will never work anyway when a symlink along one of those paths is changed because the directory it points to was moved. Also add a test moving a submodule into a deeper directory to catch any future breakage here and to document what has to be done when a submodule needs to be moved until git mv learns to do that. Simply moving it to the new location doesn't work, as the core.worktree and possibly the gitfile setting too will be wrong. So it has to be removed from filesystem and index, then the new location has to be added into the index and the .gitmodules file has to be updated. After that a git submodule update will check out the submodule at the new location. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-03-05 01:15:36 +04:00
git rm --cached submodule2 &&
rm -rf submodule2 &&
mkdir -p "moved/sub module" &&
git update-index --add --cacheinfo 160000 $H "moved/sub module" &&
git config -f .gitmodules submodule.submodule2.path "moved/sub module" &&
submodules: refactor computation of relative gitdir path In module_clone() the rel_gitdir variable was computed differently when "git rev-parse --git-dir" returned a relative path than when it returned an absolute path. This is not optimal, as different code paths are used depending on the return value of that command. Fix that by reusing the differing path components computed for setting the core.worktree config setting, which leaves a single code path for setting both instead of having three and makes the code much shorter. This also fixes the bug that in the computation of how many directories have to be traversed up to hit the root directory of the submodule the name of the submodule was used where the path should have been used. This lead to problems after renaming submodules into another directory level. Even though the "(cd $somewhere && pwd)" approach breaks the flexibility of symlinks, that is no issue here as we have to have one relative path pointing from the work tree to the gitdir and another pointing back, which will never work anyway when a symlink along one of those paths is changed because the directory it points to was moved. Also add a test moving a submodule into a deeper directory to catch any future breakage here and to document what has to be done when a submodule needs to be moved until git mv learns to do that. Simply moving it to the new location doesn't work, as the core.worktree and possibly the gitfile setting too will be wrong. So it has to be removed from filesystem and index, then the new location has to be added into the index and the .gitmodules file has to be updated. After that a git submodule update will check out the submodule at the new location. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-03-05 01:15:36 +04:00
git commit -am "post move" &&
git submodule update &&
git status > out &&
sed "s/$H2/XXX/" out >actual &&
submodules: refactor computation of relative gitdir path In module_clone() the rel_gitdir variable was computed differently when "git rev-parse --git-dir" returned a relative path than when it returned an absolute path. This is not optimal, as different code paths are used depending on the return value of that command. Fix that by reusing the differing path components computed for setting the core.worktree config setting, which leaves a single code path for setting both instead of having three and makes the code much shorter. This also fixes the bug that in the computation of how many directories have to be traversed up to hit the root directory of the submodule the name of the submodule was used where the path should have been used. This lead to problems after renaming submodules into another directory level. Even though the "(cd $somewhere && pwd)" approach breaks the flexibility of symlinks, that is no issue here as we have to have one relative path pointing from the work tree to the gitdir and another pointing back, which will never work anyway when a symlink along one of those paths is changed because the directory it points to was moved. Also add a test moving a submodule into a deeper directory to catch any future breakage here and to document what has to be done when a submodule needs to be moved until git mv learns to do that. Simply moving it to the new location doesn't work, as the core.worktree and possibly the gitfile setting too will be wrong. So it has to be removed from filesystem and index, then the new location has to be added into the index and the .gitmodules file has to be updated. After that a git submodule update will check out the submodule at the new location. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-03-05 01:15:36 +04:00
test_cmp expect actual
)
'
test_expect_success SYMLINKS 'submodule update can handle symbolic links in pwd' '
mkdir -p linked/dir &&
ln -s linked/dir linkto &&
(cd linkto &&
git clone "$TRASH_DIRECTORY"/super_update_r2 super &&
(cd super &&
git submodule update --init --recursive
)
)
'
test_expect_success 'submodule update clone shallow submodule' '
test_when_finished "rm -rf super3" &&
first=$(git -C cloned rev-parse HEAD:submodule) &&
second=$(git -C submodule rev-parse HEAD) &&
commit_count=$(git -C submodule rev-list --count $first^..$second) &&
git clone cloned super3 &&
pwd=$(pwd) &&
(
cd super3 &&
sed -e "s#url = ../#url = file://$pwd/#" <.gitmodules >.gitmodules.tmp &&
mv -f .gitmodules.tmp .gitmodules &&
git submodule update --init --depth=$commit_count &&
git -C submodule log --oneline >out &&
test_line_count = 1 out
)
'
test_expect_success 'submodule update clone shallow submodule outside of depth' '
test_when_finished "rm -rf super3" &&
git clone cloned super3 &&
pwd=$(pwd) &&
(
cd super3 &&
sed -e "s#url = ../#url = file://$pwd/#" <.gitmodules >.gitmodules.tmp &&
mv -f .gitmodules.tmp .gitmodules &&
# Some protocol versions (e.g. 2) support fetching
# unadvertised objects, so restrict this test to v0.
test_must_fail env GIT_TEST_PROTOCOL_VERSION=0 \
git submodule update --init --depth=1 2>actual &&
test_i18ngrep "Direct fetching of that commit failed." actual &&
git -C ../submodule config uploadpack.allowReachableSHA1InWant true &&
git submodule update --init --depth=1 >actual &&
git -C submodule log --oneline >out &&
test_line_count = 1 out
)
'
test_expect_success 'submodule update --recursive drops module name before recursing' '
(cd super2 &&
(cd deeper/submodule/subsubmodule &&
git checkout HEAD^
) &&
git submodule update --recursive deeper/submodule >actual &&
test_i18ngrep "Submodule path .deeper/submodule/subsubmodule.: checked out" actual
)
'
test_expect_success 'submodule update can be run in parallel' '
(cd super2 &&
GIT_TRACE=$(pwd)/trace.out git submodule update --jobs 7 &&
grep "7 tasks" trace.out &&
git config submodule.fetchJobs 8 &&
GIT_TRACE=$(pwd)/trace.out git submodule update &&
grep "8 tasks" trace.out &&
GIT_TRACE=$(pwd)/trace.out git submodule update --jobs 9 &&
grep "9 tasks" trace.out
)
'
test_expect_success 'git clone passes the parallel jobs config on to submodules' '
test_when_finished "rm -rf super4" &&
GIT_TRACE=$(pwd)/trace.out git clone --recurse-submodules --jobs 7 . super4 &&
grep "7 tasks" trace.out &&
rm -rf super4 &&
git config --global submodule.fetchJobs 8 &&
GIT_TRACE=$(pwd)/trace.out git clone --recurse-submodules . super4 &&
grep "8 tasks" trace.out &&
rm -rf super4 &&
GIT_TRACE=$(pwd)/trace.out git clone --recurse-submodules --jobs 9 . super4 &&
grep "9 tasks" trace.out &&
rm -rf super4
'
test_expect_success 'submodule update --quiet passes quietness to merge/rebase' '
(cd super &&
test_commit -C rebasing message &&
git submodule update --rebase --quiet >out 2>err &&
test_must_be_empty out &&
test_must_be_empty err &&
git submodule update --rebase >out 2>err &&
test_file_not_empty out &&
test_must_be_empty err
)
'
test_expect_success 'submodule update --quiet passes quietness to fetch with a shallow clone' '
test_when_finished "rm -rf super4 super5 super6" &&
git clone . super4 &&
(cd super4 &&
git submodule add --quiet file://"$TRASH_DIRECTORY"/submodule submodule3 &&
git commit -am "setup submodule3"
) &&
(cd submodule &&
test_commit line6 file
) &&
git clone super4 super5 &&
(cd super5 &&
git submodule update --quiet --init --depth=1 submodule3 >out 2>err &&
test_must_be_empty out &&
test_must_be_empty err
) &&
git clone super4 super6 &&
(cd super6 &&
git submodule update --init --depth=1 submodule3 >out 2>err &&
test_file_not_empty out &&
test_file_not_empty err
)
'
test_expect_success 'submodule update --filter requires --init' '
test_expect_code 129 git -C super submodule update --filter blob:none
'
test_expect_success 'submodule update --filter sets partial clone settings' '
test_when_finished "rm -rf super-filter" &&
git clone cloned super-filter &&
git -C super-filter submodule update --init --filter blob:none &&
test_cmp_config -C super-filter/submodule true remote.origin.promisor &&
test_cmp_config -C super-filter/submodule blob:none remote.origin.partialclonefilter
'
# NEEDSWORK: Clean up the tests so that we can reuse the test setup.
# Don't reuse the existing repos because the earlier tests have
# intentionally disruptive configurations.
test_expect_success 'setup clean recursive superproject' '
git init bottom &&
test_commit -C bottom "bottom" &&
git init middle &&
git -C middle submodule add ../bottom bottom &&
git -C middle commit -m "middle" &&
git init top &&
git -C top submodule add ../middle middle &&
git -C top commit -m "top" &&
git clone --recurse-submodules top top-clean
'
test_expect_success 'submodule update should skip unmerged submodules' '
test_when_finished "rm -fr top-cloned" &&
cp -r top-clean top-cloned &&
# Create an upstream commit in each repo, starting with bottom
test_commit -C bottom upstream_commit &&
# Create middle commit
git -C middle/bottom fetch &&
git -C middle/bottom checkout -f FETCH_HEAD &&
git -C middle add bottom &&
git -C middle commit -m "upstream_commit" &&
# Create top commit
git -C top/middle fetch &&
git -C top/middle checkout -f FETCH_HEAD &&
git -C top add middle &&
git -C top commit -m "upstream_commit" &&
# Create a downstream conflict
test_commit -C top-cloned/middle/bottom downstream_commit &&
git -C top-cloned/middle add bottom &&
git -C top-cloned/middle commit -m "downstream_commit" &&
git -C top-cloned/middle fetch --recurse-submodules origin &&
test_must_fail git -C top-cloned/middle merge origin/main &&
# Make the update of "middle" a no-op, otherwise we error out
# because of its unmerged state
test_config -C top-cloned submodule.middle.update !true &&
git -C top-cloned submodule update --recursive 2>actual.err &&
cat >expect.err <<-\EOF &&
Skipping unmerged submodule middle/bottom
EOF
test_cmp expect.err actual.err
'
test_expect_success 'submodule update --recursive skip submodules with strategy=none' '
test_when_finished "rm -fr top-cloned" &&
cp -r top-clean top-cloned &&
test_commit -C top-cloned/middle/bottom downstream_commit &&
git -C top-cloned/middle config submodule.bottom.update none &&
git -C top-cloned submodule update --recursive 2>actual.err &&
cat >expect.err <<-\EOF &&
Skipping submodule '\''middle/bottom'\''
EOF
test_cmp expect.err actual.err
'
test_done