2009-08-19 09:45:20 +08:00
|
|
|
#!/bin/sh
|
|
|
|
|
#
|
|
|
|
|
# Copyright (c) 2009 Johan Herland
|
|
|
|
|
#
|
|
|
|
|
|
|
|
|
|
test_description='Test "git submodule foreach"
|
|
|
|
|
|
|
|
|
|
This test verifies that "git submodule foreach" correctly visits all submodules
|
|
|
|
|
that are currently checked out.
|
|
|
|
|
'
|
|
|
|
|
|
2020-11-19 07:44:39 +08:00
|
|
|
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 07:44:19 +08:00
|
|
|
export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME
|
|
|
|
|
|
2024-09-26 19:46:11 +08:00
|
|
|
TEST_PASSES_SANITIZE_LEAK=true
|
2009-08-19 09:45:20 +08:00
|
|
|
. ./test-lib.sh
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
test_expect_success 'setup a submodule tree' '
|
2022-07-30 03:21:40 +08:00
|
|
|
git config --global protocol.file.allow always &&
|
2009-08-19 09:45:20 +08:00
|
|
|
echo file > file &&
|
|
|
|
|
git add file &&
|
|
|
|
|
test_tick &&
|
2010-09-02 05:28:27 +08:00
|
|
|
git commit -m upstream &&
|
2009-08-19 09:45:20 +08:00
|
|
|
git clone . super &&
|
|
|
|
|
git clone super submodule &&
|
|
|
|
|
(
|
|
|
|
|
cd super &&
|
|
|
|
|
git submodule add ../submodule sub1 &&
|
|
|
|
|
git submodule add ../submodule sub2 &&
|
|
|
|
|
git submodule add ../submodule sub3 &&
|
|
|
|
|
git config -f .gitmodules --rename-section \
|
|
|
|
|
submodule.sub1 submodule.foo1 &&
|
|
|
|
|
git config -f .gitmodules --rename-section \
|
|
|
|
|
submodule.sub2 submodule.foo2 &&
|
|
|
|
|
git config -f .gitmodules --rename-section \
|
|
|
|
|
submodule.sub3 submodule.foo3 &&
|
2010-09-02 05:28:27 +08:00
|
|
|
git add .gitmodules &&
|
2009-08-19 09:45:20 +08:00
|
|
|
test_tick &&
|
|
|
|
|
git commit -m "submodules" &&
|
|
|
|
|
git submodule init sub1 &&
|
|
|
|
|
git submodule init sub2 &&
|
|
|
|
|
git submodule init sub3
|
|
|
|
|
) &&
|
|
|
|
|
(
|
|
|
|
|
cd submodule &&
|
|
|
|
|
echo different > file &&
|
|
|
|
|
git add file &&
|
|
|
|
|
test_tick &&
|
|
|
|
|
git commit -m "different"
|
|
|
|
|
) &&
|
|
|
|
|
(
|
|
|
|
|
cd super &&
|
|
|
|
|
(
|
|
|
|
|
cd sub3 &&
|
|
|
|
|
git pull
|
|
|
|
|
) &&
|
|
|
|
|
git add sub3 &&
|
|
|
|
|
test_tick &&
|
|
|
|
|
git commit -m "update sub3"
|
|
|
|
|
)
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
sub1sha1=$(cd super/sub1 && git rev-parse HEAD)
|
|
|
|
|
sub3sha1=$(cd super/sub3 && git rev-parse HEAD)
|
|
|
|
|
|
2010-05-22 00:10:10 +08:00
|
|
|
pwd=$(pwd)
|
|
|
|
|
|
2009-08-19 09:45:20 +08:00
|
|
|
cat > expect <<EOF
|
|
|
|
|
Entering 'sub1'
|
2010-05-22 00:10:10 +08:00
|
|
|
$pwd/clone-foo1-sub1-$sub1sha1
|
2009-08-19 09:45:20 +08:00
|
|
|
Entering 'sub3'
|
2010-05-22 00:10:10 +08:00
|
|
|
$pwd/clone-foo3-sub3-$sub3sha1
|
2009-08-19 09:45:20 +08:00
|
|
|
EOF
|
|
|
|
|
|
|
|
|
|
test_expect_success 'test basic "submodule foreach" usage' '
|
|
|
|
|
git clone super clone &&
|
|
|
|
|
(
|
|
|
|
|
cd clone &&
|
|
|
|
|
git submodule update --init -- sub1 sub3 &&
|
2010-05-22 00:10:10 +08:00
|
|
|
git submodule foreach "echo \$toplevel-\$name-\$path-\$sha1" > ../actual &&
|
|
|
|
|
git config foo.bar zar &&
|
|
|
|
|
git submodule foreach "git config --file \"\$toplevel/.git/config\" foo.bar"
|
2009-08-19 09:45:20 +08:00
|
|
|
) &&
|
2021-02-11 09:53:53 +08:00
|
|
|
test_cmp expect actual
|
2009-08-19 09:45:20 +08:00
|
|
|
'
|
|
|
|
|
|
2013-06-16 22:18:18 +08:00
|
|
|
cat >expect <<EOF
|
|
|
|
|
Entering '../sub1'
|
2018-05-09 08:29:51 +08:00
|
|
|
$pwd/clone-foo1-sub1-../sub1-$sub1sha1
|
2013-06-16 22:18:18 +08:00
|
|
|
Entering '../sub3'
|
2018-05-09 08:29:51 +08:00
|
|
|
$pwd/clone-foo3-sub3-../sub3-$sub3sha1
|
2013-06-16 22:18:18 +08:00
|
|
|
EOF
|
|
|
|
|
|
|
|
|
|
test_expect_success 'test "submodule foreach" from subdirectory' '
|
|
|
|
|
mkdir clone/sub &&
|
|
|
|
|
(
|
|
|
|
|
cd clone/sub &&
|
2018-05-09 08:29:51 +08:00
|
|
|
git submodule foreach "echo \$toplevel-\$name-\$sm_path-\$displaypath-\$sha1" >../../actual
|
2013-06-16 22:18:18 +08:00
|
|
|
) &&
|
2021-02-11 09:53:53 +08:00
|
|
|
test_cmp expect actual
|
2013-06-16 22:18:18 +08:00
|
|
|
'
|
|
|
|
|
|
2009-08-19 09:45:22 +08:00
|
|
|
test_expect_success 'setup nested submodules' '
|
|
|
|
|
git clone submodule nested1 &&
|
|
|
|
|
git clone submodule nested2 &&
|
|
|
|
|
git clone submodule nested3 &&
|
|
|
|
|
(
|
|
|
|
|
cd nested3 &&
|
|
|
|
|
git submodule add ../submodule submodule &&
|
|
|
|
|
test_tick &&
|
|
|
|
|
git commit -m "submodule" &&
|
|
|
|
|
git submodule init submodule
|
|
|
|
|
) &&
|
|
|
|
|
(
|
|
|
|
|
cd nested2 &&
|
|
|
|
|
git submodule add ../nested3 nested3 &&
|
|
|
|
|
test_tick &&
|
|
|
|
|
git commit -m "nested3" &&
|
|
|
|
|
git submodule init nested3
|
|
|
|
|
) &&
|
|
|
|
|
(
|
|
|
|
|
cd nested1 &&
|
|
|
|
|
git submodule add ../nested2 nested2 &&
|
|
|
|
|
test_tick &&
|
|
|
|
|
git commit -m "nested2" &&
|
|
|
|
|
git submodule init nested2
|
|
|
|
|
) &&
|
|
|
|
|
(
|
|
|
|
|
cd super &&
|
|
|
|
|
git submodule add ../nested1 nested1 &&
|
|
|
|
|
test_tick &&
|
|
|
|
|
git commit -m "nested1" &&
|
|
|
|
|
git submodule init nested1
|
|
|
|
|
)
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
test_expect_success 'use "submodule foreach" to checkout 2nd level submodule' '
|
|
|
|
|
git clone super clone2 &&
|
|
|
|
|
(
|
|
|
|
|
cd clone2 &&
|
2011-08-16 05:17:46 +08:00
|
|
|
test_must_fail git rev-parse --resolve-git-dir sub1/.git &&
|
|
|
|
|
test_must_fail git rev-parse --resolve-git-dir sub2/.git &&
|
|
|
|
|
test_must_fail git rev-parse --resolve-git-dir sub3/.git &&
|
|
|
|
|
test_must_fail git rev-parse --resolve-git-dir nested1/.git &&
|
2009-08-19 09:45:22 +08:00
|
|
|
git submodule update --init &&
|
2011-08-16 05:17:46 +08:00
|
|
|
git rev-parse --resolve-git-dir sub1/.git &&
|
|
|
|
|
git rev-parse --resolve-git-dir sub2/.git &&
|
|
|
|
|
git rev-parse --resolve-git-dir sub3/.git &&
|
|
|
|
|
git rev-parse --resolve-git-dir nested1/.git &&
|
|
|
|
|
test_must_fail git rev-parse --resolve-git-dir nested1/nested2/.git &&
|
2009-08-19 09:45:22 +08:00
|
|
|
git submodule foreach "git submodule update --init" &&
|
2013-08-10 04:12:54 +08:00
|
|
|
git rev-parse --resolve-git-dir nested1/nested2/.git &&
|
2011-08-16 05:17:46 +08:00
|
|
|
test_must_fail git rev-parse --resolve-git-dir nested1/nested2/nested3/.git
|
2009-08-19 09:45:22 +08:00
|
|
|
)
|
|
|
|
|
'
|
|
|
|
|
|
2022-11-08 22:10:35 +08:00
|
|
|
test_expect_success 'usage: foreach -- --not-an-option' '
|
|
|
|
|
test_expect_code 1 git submodule foreach -- --not-an-option &&
|
|
|
|
|
test_expect_code 1 git -C clone2 submodule foreach -- --not-an-option
|
|
|
|
|
'
|
|
|
|
|
|
2009-08-19 09:45:22 +08:00
|
|
|
test_expect_success 'use "foreach --recursive" to checkout all submodules' '
|
|
|
|
|
(
|
|
|
|
|
cd clone2 &&
|
|
|
|
|
git submodule foreach --recursive "git submodule update --init" &&
|
2011-08-16 05:17:46 +08:00
|
|
|
git rev-parse --resolve-git-dir nested1/nested2/nested3/.git &&
|
|
|
|
|
git rev-parse --resolve-git-dir nested1/nested2/nested3/submodule/.git
|
2009-08-19 09:45:22 +08:00
|
|
|
)
|
|
|
|
|
'
|
|
|
|
|
|
|
|
|
|
cat > expect <<EOF
|
|
|
|
|
Entering 'nested1'
|
|
|
|
|
Entering 'nested1/nested2'
|
|
|
|
|
Entering 'nested1/nested2/nested3'
|
|
|
|
|
Entering 'nested1/nested2/nested3/submodule'
|
|
|
|
|
Entering 'sub1'
|
|
|
|
|
Entering 'sub2'
|
|
|
|
|
Entering 'sub3'
|
|
|
|
|
EOF
|
|
|
|
|
|
|
|
|
|
test_expect_success 'test messages from "foreach --recursive"' '
|
|
|
|
|
(
|
|
|
|
|
cd clone2 &&
|
|
|
|
|
git submodule foreach --recursive "true" > ../actual
|
|
|
|
|
) &&
|
2021-02-11 09:53:53 +08:00
|
|
|
test_cmp expect actual
|
2009-08-19 09:45:22 +08:00
|
|
|
'
|
|
|
|
|
|
2016-03-30 09:27:41 +08:00
|
|
|
cat > expect <<EOF
|
|
|
|
|
Entering '../nested1'
|
|
|
|
|
Entering '../nested1/nested2'
|
|
|
|
|
Entering '../nested1/nested2/nested3'
|
|
|
|
|
Entering '../nested1/nested2/nested3/submodule'
|
|
|
|
|
Entering '../sub1'
|
|
|
|
|
Entering '../sub2'
|
|
|
|
|
Entering '../sub3'
|
|
|
|
|
EOF
|
|
|
|
|
|
|
|
|
|
test_expect_success 'test messages from "foreach --recursive" from subdirectory' '
|
|
|
|
|
(
|
|
|
|
|
cd clone2 &&
|
|
|
|
|
mkdir untracked &&
|
|
|
|
|
cd untracked &&
|
|
|
|
|
git submodule foreach --recursive >../../actual
|
|
|
|
|
) &&
|
2021-02-11 09:53:53 +08:00
|
|
|
test_cmp expect actual
|
2016-03-30 09:27:41 +08:00
|
|
|
'
|
submodule foreach: correct '$path' in nested submodules from a subdirectory
When running 'git submodule foreach --recursive' from a subdirectory of
your repository, nested submodules get a bogus value for $path:
For a submodule 'sub' that contains a nested submodule 'nested',
running 'git -C dir submodule foreach echo $path' from the root of the
superproject would report path='../nested' for the nested submodule.
The first part '../' is derived from the logic computing the relative
path from $pwd to the root of the superproject. The second part is the
submodule path inside the submodule. This value is of little use and is
hard to document.
Also, in git-submodule.txt, $path is documented to be the "name of the
submodule directory relative to the superproject", but "the
superproject" is ambiguous.
To resolve both these issues, we could:
(a) Change "the superproject" to "its immediate superproject", so
$path would be "nested" instead of "../nested".
(b) Change "the superproject" to "the superproject the original
command was run from", so $path would be "sub/nested" instead of
"../nested".
(c) Change "the superproject" to "the directory the original command
was run from", so $path would be "../sub/nested" instead of
"../nested".
The behavior for (c) was attempted to be introduced in 091a6eb0fe
(submodule: drop the top-level requirement, 2013-06-16) with the intent
for $path to be relative from $pwd to the submodule worktree, but that
did not work for nested submodules, as the intermittent submodules
were not included in the path.
If we were to fix the meaning of the $path using (a), we would break
any existing submodule user that runs foreach from non-root of the
superproject as the non-nested submodule '../sub' would change its
path to 'sub'.
If we were to fix the meaning of $path using (b), then we would break
any user that uses nested submodules (even from the root directory)
as the 'nested' would become 'sub/nested'.
If we were to fix the meaning of $path using (c), then we would break
the same users as in (b) as 'nested' would become 'sub/nested' from
the root directory of the superproject.
All groups can be found in the wild. The author has no data if one group
outweighs the other by large margin, and offending each one seems equally
bad at first. However in the authors imagination it is better to go with
(a) as running from a sub directory sounds like it is carried out by a
human rather than by some automation task. With a human on the keyboard
the feedback loop is short and the changed behavior can be adapted to
quickly unlike some automation that can break silently.
Discussed-with: Ramsay Jones <ramsay@ramsayjones.plus.com>
Signed-off-by: Prathamesh Chavan <pc44800@gmail.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-09 08:29:49 +08:00
|
|
|
sub1sha1=$(cd clone2/sub1 && git rev-parse HEAD)
|
|
|
|
|
sub2sha1=$(cd clone2/sub2 && git rev-parse HEAD)
|
|
|
|
|
sub3sha1=$(cd clone2/sub3 && git rev-parse HEAD)
|
|
|
|
|
nested1sha1=$(cd clone2/nested1 && git rev-parse HEAD)
|
|
|
|
|
nested2sha1=$(cd clone2/nested1/nested2 && git rev-parse HEAD)
|
|
|
|
|
nested3sha1=$(cd clone2/nested1/nested2/nested3 && git rev-parse HEAD)
|
|
|
|
|
submodulesha1=$(cd clone2/nested1/nested2/nested3/submodule && git rev-parse HEAD)
|
|
|
|
|
|
|
|
|
|
cat >expect <<EOF
|
|
|
|
|
Entering '../nested1'
|
2018-05-09 08:29:51 +08:00
|
|
|
toplevel: $pwd/clone2 name: nested1 path: nested1 displaypath: ../nested1 hash: $nested1sha1
|
submodule foreach: correct '$path' in nested submodules from a subdirectory
When running 'git submodule foreach --recursive' from a subdirectory of
your repository, nested submodules get a bogus value for $path:
For a submodule 'sub' that contains a nested submodule 'nested',
running 'git -C dir submodule foreach echo $path' from the root of the
superproject would report path='../nested' for the nested submodule.
The first part '../' is derived from the logic computing the relative
path from $pwd to the root of the superproject. The second part is the
submodule path inside the submodule. This value is of little use and is
hard to document.
Also, in git-submodule.txt, $path is documented to be the "name of the
submodule directory relative to the superproject", but "the
superproject" is ambiguous.
To resolve both these issues, we could:
(a) Change "the superproject" to "its immediate superproject", so
$path would be "nested" instead of "../nested".
(b) Change "the superproject" to "the superproject the original
command was run from", so $path would be "sub/nested" instead of
"../nested".
(c) Change "the superproject" to "the directory the original command
was run from", so $path would be "../sub/nested" instead of
"../nested".
The behavior for (c) was attempted to be introduced in 091a6eb0fe
(submodule: drop the top-level requirement, 2013-06-16) with the intent
for $path to be relative from $pwd to the submodule worktree, but that
did not work for nested submodules, as the intermittent submodules
were not included in the path.
If we were to fix the meaning of the $path using (a), we would break
any existing submodule user that runs foreach from non-root of the
superproject as the non-nested submodule '../sub' would change its
path to 'sub'.
If we were to fix the meaning of $path using (b), then we would break
any user that uses nested submodules (even from the root directory)
as the 'nested' would become 'sub/nested'.
If we were to fix the meaning of $path using (c), then we would break
the same users as in (b) as 'nested' would become 'sub/nested' from
the root directory of the superproject.
All groups can be found in the wild. The author has no data if one group
outweighs the other by large margin, and offending each one seems equally
bad at first. However in the authors imagination it is better to go with
(a) as running from a sub directory sounds like it is carried out by a
human rather than by some automation task. With a human on the keyboard
the feedback loop is short and the changed behavior can be adapted to
quickly unlike some automation that can break silently.
Discussed-with: Ramsay Jones <ramsay@ramsayjones.plus.com>
Signed-off-by: Prathamesh Chavan <pc44800@gmail.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-09 08:29:49 +08:00
|
|
|
Entering '../nested1/nested2'
|
2018-05-09 08:29:51 +08:00
|
|
|
toplevel: $pwd/clone2/nested1 name: nested2 path: nested2 displaypath: ../nested1/nested2 hash: $nested2sha1
|
submodule foreach: correct '$path' in nested submodules from a subdirectory
When running 'git submodule foreach --recursive' from a subdirectory of
your repository, nested submodules get a bogus value for $path:
For a submodule 'sub' that contains a nested submodule 'nested',
running 'git -C dir submodule foreach echo $path' from the root of the
superproject would report path='../nested' for the nested submodule.
The first part '../' is derived from the logic computing the relative
path from $pwd to the root of the superproject. The second part is the
submodule path inside the submodule. This value is of little use and is
hard to document.
Also, in git-submodule.txt, $path is documented to be the "name of the
submodule directory relative to the superproject", but "the
superproject" is ambiguous.
To resolve both these issues, we could:
(a) Change "the superproject" to "its immediate superproject", so
$path would be "nested" instead of "../nested".
(b) Change "the superproject" to "the superproject the original
command was run from", so $path would be "sub/nested" instead of
"../nested".
(c) Change "the superproject" to "the directory the original command
was run from", so $path would be "../sub/nested" instead of
"../nested".
The behavior for (c) was attempted to be introduced in 091a6eb0fe
(submodule: drop the top-level requirement, 2013-06-16) with the intent
for $path to be relative from $pwd to the submodule worktree, but that
did not work for nested submodules, as the intermittent submodules
were not included in the path.
If we were to fix the meaning of the $path using (a), we would break
any existing submodule user that runs foreach from non-root of the
superproject as the non-nested submodule '../sub' would change its
path to 'sub'.
If we were to fix the meaning of $path using (b), then we would break
any user that uses nested submodules (even from the root directory)
as the 'nested' would become 'sub/nested'.
If we were to fix the meaning of $path using (c), then we would break
the same users as in (b) as 'nested' would become 'sub/nested' from
the root directory of the superproject.
All groups can be found in the wild. The author has no data if one group
outweighs the other by large margin, and offending each one seems equally
bad at first. However in the authors imagination it is better to go with
(a) as running from a sub directory sounds like it is carried out by a
human rather than by some automation task. With a human on the keyboard
the feedback loop is short and the changed behavior can be adapted to
quickly unlike some automation that can break silently.
Discussed-with: Ramsay Jones <ramsay@ramsayjones.plus.com>
Signed-off-by: Prathamesh Chavan <pc44800@gmail.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-09 08:29:49 +08:00
|
|
|
Entering '../nested1/nested2/nested3'
|
2018-05-09 08:29:51 +08:00
|
|
|
toplevel: $pwd/clone2/nested1/nested2 name: nested3 path: nested3 displaypath: ../nested1/nested2/nested3 hash: $nested3sha1
|
submodule foreach: correct '$path' in nested submodules from a subdirectory
When running 'git submodule foreach --recursive' from a subdirectory of
your repository, nested submodules get a bogus value for $path:
For a submodule 'sub' that contains a nested submodule 'nested',
running 'git -C dir submodule foreach echo $path' from the root of the
superproject would report path='../nested' for the nested submodule.
The first part '../' is derived from the logic computing the relative
path from $pwd to the root of the superproject. The second part is the
submodule path inside the submodule. This value is of little use and is
hard to document.
Also, in git-submodule.txt, $path is documented to be the "name of the
submodule directory relative to the superproject", but "the
superproject" is ambiguous.
To resolve both these issues, we could:
(a) Change "the superproject" to "its immediate superproject", so
$path would be "nested" instead of "../nested".
(b) Change "the superproject" to "the superproject the original
command was run from", so $path would be "sub/nested" instead of
"../nested".
(c) Change "the superproject" to "the directory the original command
was run from", so $path would be "../sub/nested" instead of
"../nested".
The behavior for (c) was attempted to be introduced in 091a6eb0fe
(submodule: drop the top-level requirement, 2013-06-16) with the intent
for $path to be relative from $pwd to the submodule worktree, but that
did not work for nested submodules, as the intermittent submodules
were not included in the path.
If we were to fix the meaning of the $path using (a), we would break
any existing submodule user that runs foreach from non-root of the
superproject as the non-nested submodule '../sub' would change its
path to 'sub'.
If we were to fix the meaning of $path using (b), then we would break
any user that uses nested submodules (even from the root directory)
as the 'nested' would become 'sub/nested'.
If we were to fix the meaning of $path using (c), then we would break
the same users as in (b) as 'nested' would become 'sub/nested' from
the root directory of the superproject.
All groups can be found in the wild. The author has no data if one group
outweighs the other by large margin, and offending each one seems equally
bad at first. However in the authors imagination it is better to go with
(a) as running from a sub directory sounds like it is carried out by a
human rather than by some automation task. With a human on the keyboard
the feedback loop is short and the changed behavior can be adapted to
quickly unlike some automation that can break silently.
Discussed-with: Ramsay Jones <ramsay@ramsayjones.plus.com>
Signed-off-by: Prathamesh Chavan <pc44800@gmail.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-09 08:29:49 +08:00
|
|
|
Entering '../nested1/nested2/nested3/submodule'
|
2018-05-09 08:29:51 +08:00
|
|
|
toplevel: $pwd/clone2/nested1/nested2/nested3 name: submodule path: submodule displaypath: ../nested1/nested2/nested3/submodule hash: $submodulesha1
|
submodule foreach: correct '$path' in nested submodules from a subdirectory
When running 'git submodule foreach --recursive' from a subdirectory of
your repository, nested submodules get a bogus value for $path:
For a submodule 'sub' that contains a nested submodule 'nested',
running 'git -C dir submodule foreach echo $path' from the root of the
superproject would report path='../nested' for the nested submodule.
The first part '../' is derived from the logic computing the relative
path from $pwd to the root of the superproject. The second part is the
submodule path inside the submodule. This value is of little use and is
hard to document.
Also, in git-submodule.txt, $path is documented to be the "name of the
submodule directory relative to the superproject", but "the
superproject" is ambiguous.
To resolve both these issues, we could:
(a) Change "the superproject" to "its immediate superproject", so
$path would be "nested" instead of "../nested".
(b) Change "the superproject" to "the superproject the original
command was run from", so $path would be "sub/nested" instead of
"../nested".
(c) Change "the superproject" to "the directory the original command
was run from", so $path would be "../sub/nested" instead of
"../nested".
The behavior for (c) was attempted to be introduced in 091a6eb0fe
(submodule: drop the top-level requirement, 2013-06-16) with the intent
for $path to be relative from $pwd to the submodule worktree, but that
did not work for nested submodules, as the intermittent submodules
were not included in the path.
If we were to fix the meaning of the $path using (a), we would break
any existing submodule user that runs foreach from non-root of the
superproject as the non-nested submodule '../sub' would change its
path to 'sub'.
If we were to fix the meaning of $path using (b), then we would break
any user that uses nested submodules (even from the root directory)
as the 'nested' would become 'sub/nested'.
If we were to fix the meaning of $path using (c), then we would break
the same users as in (b) as 'nested' would become 'sub/nested' from
the root directory of the superproject.
All groups can be found in the wild. The author has no data if one group
outweighs the other by large margin, and offending each one seems equally
bad at first. However in the authors imagination it is better to go with
(a) as running from a sub directory sounds like it is carried out by a
human rather than by some automation task. With a human on the keyboard
the feedback loop is short and the changed behavior can be adapted to
quickly unlike some automation that can break silently.
Discussed-with: Ramsay Jones <ramsay@ramsayjones.plus.com>
Signed-off-by: Prathamesh Chavan <pc44800@gmail.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-09 08:29:49 +08:00
|
|
|
Entering '../sub1'
|
2018-05-09 08:29:51 +08:00
|
|
|
toplevel: $pwd/clone2 name: foo1 path: sub1 displaypath: ../sub1 hash: $sub1sha1
|
submodule foreach: correct '$path' in nested submodules from a subdirectory
When running 'git submodule foreach --recursive' from a subdirectory of
your repository, nested submodules get a bogus value for $path:
For a submodule 'sub' that contains a nested submodule 'nested',
running 'git -C dir submodule foreach echo $path' from the root of the
superproject would report path='../nested' for the nested submodule.
The first part '../' is derived from the logic computing the relative
path from $pwd to the root of the superproject. The second part is the
submodule path inside the submodule. This value is of little use and is
hard to document.
Also, in git-submodule.txt, $path is documented to be the "name of the
submodule directory relative to the superproject", but "the
superproject" is ambiguous.
To resolve both these issues, we could:
(a) Change "the superproject" to "its immediate superproject", so
$path would be "nested" instead of "../nested".
(b) Change "the superproject" to "the superproject the original
command was run from", so $path would be "sub/nested" instead of
"../nested".
(c) Change "the superproject" to "the directory the original command
was run from", so $path would be "../sub/nested" instead of
"../nested".
The behavior for (c) was attempted to be introduced in 091a6eb0fe
(submodule: drop the top-level requirement, 2013-06-16) with the intent
for $path to be relative from $pwd to the submodule worktree, but that
did not work for nested submodules, as the intermittent submodules
were not included in the path.
If we were to fix the meaning of the $path using (a), we would break
any existing submodule user that runs foreach from non-root of the
superproject as the non-nested submodule '../sub' would change its
path to 'sub'.
If we were to fix the meaning of $path using (b), then we would break
any user that uses nested submodules (even from the root directory)
as the 'nested' would become 'sub/nested'.
If we were to fix the meaning of $path using (c), then we would break
the same users as in (b) as 'nested' would become 'sub/nested' from
the root directory of the superproject.
All groups can be found in the wild. The author has no data if one group
outweighs the other by large margin, and offending each one seems equally
bad at first. However in the authors imagination it is better to go with
(a) as running from a sub directory sounds like it is carried out by a
human rather than by some automation task. With a human on the keyboard
the feedback loop is short and the changed behavior can be adapted to
quickly unlike some automation that can break silently.
Discussed-with: Ramsay Jones <ramsay@ramsayjones.plus.com>
Signed-off-by: Prathamesh Chavan <pc44800@gmail.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-09 08:29:49 +08:00
|
|
|
Entering '../sub2'
|
2018-05-09 08:29:51 +08:00
|
|
|
toplevel: $pwd/clone2 name: foo2 path: sub2 displaypath: ../sub2 hash: $sub2sha1
|
submodule foreach: correct '$path' in nested submodules from a subdirectory
When running 'git submodule foreach --recursive' from a subdirectory of
your repository, nested submodules get a bogus value for $path:
For a submodule 'sub' that contains a nested submodule 'nested',
running 'git -C dir submodule foreach echo $path' from the root of the
superproject would report path='../nested' for the nested submodule.
The first part '../' is derived from the logic computing the relative
path from $pwd to the root of the superproject. The second part is the
submodule path inside the submodule. This value is of little use and is
hard to document.
Also, in git-submodule.txt, $path is documented to be the "name of the
submodule directory relative to the superproject", but "the
superproject" is ambiguous.
To resolve both these issues, we could:
(a) Change "the superproject" to "its immediate superproject", so
$path would be "nested" instead of "../nested".
(b) Change "the superproject" to "the superproject the original
command was run from", so $path would be "sub/nested" instead of
"../nested".
(c) Change "the superproject" to "the directory the original command
was run from", so $path would be "../sub/nested" instead of
"../nested".
The behavior for (c) was attempted to be introduced in 091a6eb0fe
(submodule: drop the top-level requirement, 2013-06-16) with the intent
for $path to be relative from $pwd to the submodule worktree, but that
did not work for nested submodules, as the intermittent submodules
were not included in the path.
If we were to fix the meaning of the $path using (a), we would break
any existing submodule user that runs foreach from non-root of the
superproject as the non-nested submodule '../sub' would change its
path to 'sub'.
If we were to fix the meaning of $path using (b), then we would break
any user that uses nested submodules (even from the root directory)
as the 'nested' would become 'sub/nested'.
If we were to fix the meaning of $path using (c), then we would break
the same users as in (b) as 'nested' would become 'sub/nested' from
the root directory of the superproject.
All groups can be found in the wild. The author has no data if one group
outweighs the other by large margin, and offending each one seems equally
bad at first. However in the authors imagination it is better to go with
(a) as running from a sub directory sounds like it is carried out by a
human rather than by some automation task. With a human on the keyboard
the feedback loop is short and the changed behavior can be adapted to
quickly unlike some automation that can break silently.
Discussed-with: Ramsay Jones <ramsay@ramsayjones.plus.com>
Signed-off-by: Prathamesh Chavan <pc44800@gmail.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-09 08:29:49 +08:00
|
|
|
Entering '../sub3'
|
2018-05-09 08:29:51 +08:00
|
|
|
toplevel: $pwd/clone2 name: foo3 path: sub3 displaypath: ../sub3 hash: $sub3sha1
|
submodule foreach: correct '$path' in nested submodules from a subdirectory
When running 'git submodule foreach --recursive' from a subdirectory of
your repository, nested submodules get a bogus value for $path:
For a submodule 'sub' that contains a nested submodule 'nested',
running 'git -C dir submodule foreach echo $path' from the root of the
superproject would report path='../nested' for the nested submodule.
The first part '../' is derived from the logic computing the relative
path from $pwd to the root of the superproject. The second part is the
submodule path inside the submodule. This value is of little use and is
hard to document.
Also, in git-submodule.txt, $path is documented to be the "name of the
submodule directory relative to the superproject", but "the
superproject" is ambiguous.
To resolve both these issues, we could:
(a) Change "the superproject" to "its immediate superproject", so
$path would be "nested" instead of "../nested".
(b) Change "the superproject" to "the superproject the original
command was run from", so $path would be "sub/nested" instead of
"../nested".
(c) Change "the superproject" to "the directory the original command
was run from", so $path would be "../sub/nested" instead of
"../nested".
The behavior for (c) was attempted to be introduced in 091a6eb0fe
(submodule: drop the top-level requirement, 2013-06-16) with the intent
for $path to be relative from $pwd to the submodule worktree, but that
did not work for nested submodules, as the intermittent submodules
were not included in the path.
If we were to fix the meaning of the $path using (a), we would break
any existing submodule user that runs foreach from non-root of the
superproject as the non-nested submodule '../sub' would change its
path to 'sub'.
If we were to fix the meaning of $path using (b), then we would break
any user that uses nested submodules (even from the root directory)
as the 'nested' would become 'sub/nested'.
If we were to fix the meaning of $path using (c), then we would break
the same users as in (b) as 'nested' would become 'sub/nested' from
the root directory of the superproject.
All groups can be found in the wild. The author has no data if one group
outweighs the other by large margin, and offending each one seems equally
bad at first. However in the authors imagination it is better to go with
(a) as running from a sub directory sounds like it is carried out by a
human rather than by some automation task. With a human on the keyboard
the feedback loop is short and the changed behavior can be adapted to
quickly unlike some automation that can break silently.
Discussed-with: Ramsay Jones <ramsay@ramsayjones.plus.com>
Signed-off-by: Prathamesh Chavan <pc44800@gmail.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-09 08:29:49 +08:00
|
|
|
EOF
|
|
|
|
|
|
|
|
|
|
test_expect_success 'test "submodule foreach --recursive" from subdirectory' '
|
|
|
|
|
(
|
|
|
|
|
cd clone2/untracked &&
|
2018-05-09 08:29:51 +08:00
|
|
|
git submodule foreach --recursive "echo toplevel: \$toplevel name: \$name path: \$sm_path displaypath: \$displaypath hash: \$sha1" >../../actual
|
submodule foreach: correct '$path' in nested submodules from a subdirectory
When running 'git submodule foreach --recursive' from a subdirectory of
your repository, nested submodules get a bogus value for $path:
For a submodule 'sub' that contains a nested submodule 'nested',
running 'git -C dir submodule foreach echo $path' from the root of the
superproject would report path='../nested' for the nested submodule.
The first part '../' is derived from the logic computing the relative
path from $pwd to the root of the superproject. The second part is the
submodule path inside the submodule. This value is of little use and is
hard to document.
Also, in git-submodule.txt, $path is documented to be the "name of the
submodule directory relative to the superproject", but "the
superproject" is ambiguous.
To resolve both these issues, we could:
(a) Change "the superproject" to "its immediate superproject", so
$path would be "nested" instead of "../nested".
(b) Change "the superproject" to "the superproject the original
command was run from", so $path would be "sub/nested" instead of
"../nested".
(c) Change "the superproject" to "the directory the original command
was run from", so $path would be "../sub/nested" instead of
"../nested".
The behavior for (c) was attempted to be introduced in 091a6eb0fe
(submodule: drop the top-level requirement, 2013-06-16) with the intent
for $path to be relative from $pwd to the submodule worktree, but that
did not work for nested submodules, as the intermittent submodules
were not included in the path.
If we were to fix the meaning of the $path using (a), we would break
any existing submodule user that runs foreach from non-root of the
superproject as the non-nested submodule '../sub' would change its
path to 'sub'.
If we were to fix the meaning of $path using (b), then we would break
any user that uses nested submodules (even from the root directory)
as the 'nested' would become 'sub/nested'.
If we were to fix the meaning of $path using (c), then we would break
the same users as in (b) as 'nested' would become 'sub/nested' from
the root directory of the superproject.
All groups can be found in the wild. The author has no data if one group
outweighs the other by large margin, and offending each one seems equally
bad at first. However in the authors imagination it is better to go with
(a) as running from a sub directory sounds like it is carried out by a
human rather than by some automation task. With a human on the keyboard
the feedback loop is short and the changed behavior can be adapted to
quickly unlike some automation that can break silently.
Discussed-with: Ramsay Jones <ramsay@ramsayjones.plus.com>
Signed-off-by: Prathamesh Chavan <pc44800@gmail.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-09 08:29:49 +08:00
|
|
|
) &&
|
2021-02-11 09:53:53 +08:00
|
|
|
test_cmp expect actual
|
submodule foreach: correct '$path' in nested submodules from a subdirectory
When running 'git submodule foreach --recursive' from a subdirectory of
your repository, nested submodules get a bogus value for $path:
For a submodule 'sub' that contains a nested submodule 'nested',
running 'git -C dir submodule foreach echo $path' from the root of the
superproject would report path='../nested' for the nested submodule.
The first part '../' is derived from the logic computing the relative
path from $pwd to the root of the superproject. The second part is the
submodule path inside the submodule. This value is of little use and is
hard to document.
Also, in git-submodule.txt, $path is documented to be the "name of the
submodule directory relative to the superproject", but "the
superproject" is ambiguous.
To resolve both these issues, we could:
(a) Change "the superproject" to "its immediate superproject", so
$path would be "nested" instead of "../nested".
(b) Change "the superproject" to "the superproject the original
command was run from", so $path would be "sub/nested" instead of
"../nested".
(c) Change "the superproject" to "the directory the original command
was run from", so $path would be "../sub/nested" instead of
"../nested".
The behavior for (c) was attempted to be introduced in 091a6eb0fe
(submodule: drop the top-level requirement, 2013-06-16) with the intent
for $path to be relative from $pwd to the submodule worktree, but that
did not work for nested submodules, as the intermittent submodules
were not included in the path.
If we were to fix the meaning of the $path using (a), we would break
any existing submodule user that runs foreach from non-root of the
superproject as the non-nested submodule '../sub' would change its
path to 'sub'.
If we were to fix the meaning of $path using (b), then we would break
any user that uses nested submodules (even from the root directory)
as the 'nested' would become 'sub/nested'.
If we were to fix the meaning of $path using (c), then we would break
the same users as in (b) as 'nested' would become 'sub/nested' from
the root directory of the superproject.
All groups can be found in the wild. The author has no data if one group
outweighs the other by large margin, and offending each one seems equally
bad at first. However in the authors imagination it is better to go with
(a) as running from a sub directory sounds like it is carried out by a
human rather than by some automation task. With a human on the keyboard
the feedback loop is short and the changed behavior can be adapted to
quickly unlike some automation that can break silently.
Discussed-with: Ramsay Jones <ramsay@ramsayjones.plus.com>
Signed-off-by: Prathamesh Chavan <pc44800@gmail.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-09 08:29:49 +08:00
|
|
|
'
|
2016-03-30 09:27:41 +08:00
|
|
|
|
2009-08-19 09:45:22 +08:00
|
|
|
cat > expect <<EOF
|
|
|
|
|
nested1-nested1
|
|
|
|
|
nested2-nested2
|
|
|
|
|
nested3-nested3
|
|
|
|
|
submodule-submodule
|
|
|
|
|
foo1-sub1
|
|
|
|
|
foo2-sub2
|
|
|
|
|
foo3-sub3
|
|
|
|
|
EOF
|
|
|
|
|
|
|
|
|
|
test_expect_success 'test "foreach --quiet --recursive"' '
|
|
|
|
|
(
|
|
|
|
|
cd clone2 &&
|
|
|
|
|
git submodule foreach -q --recursive "echo \$name-\$path" > ../actual
|
|
|
|
|
) &&
|
|
|
|
|
test_cmp expect actual
|
|
|
|
|
'
|
|
|
|
|
|
2009-08-19 09:45:23 +08:00
|
|
|
test_expect_success 'use "update --recursive" to checkout all submodules' '
|
|
|
|
|
git clone super clone3 &&
|
|
|
|
|
(
|
|
|
|
|
cd clone3 &&
|
2011-08-16 05:17:46 +08:00
|
|
|
test_must_fail git rev-parse --resolve-git-dir sub1/.git &&
|
|
|
|
|
test_must_fail git rev-parse --resolve-git-dir sub2/.git &&
|
|
|
|
|
test_must_fail git rev-parse --resolve-git-dir sub3/.git &&
|
|
|
|
|
test_must_fail git rev-parse --resolve-git-dir nested1/.git &&
|
2009-08-19 09:45:23 +08:00
|
|
|
git submodule update --init --recursive &&
|
2011-08-16 05:17:46 +08:00
|
|
|
git rev-parse --resolve-git-dir sub1/.git &&
|
|
|
|
|
git rev-parse --resolve-git-dir sub2/.git &&
|
|
|
|
|
git rev-parse --resolve-git-dir sub3/.git &&
|
|
|
|
|
git rev-parse --resolve-git-dir nested1/.git &&
|
|
|
|
|
git rev-parse --resolve-git-dir nested1/nested2/.git &&
|
|
|
|
|
git rev-parse --resolve-git-dir nested1/nested2/nested3/.git &&
|
|
|
|
|
git rev-parse --resolve-git-dir nested1/nested2/nested3/submodule/.git
|
2009-08-19 09:45:23 +08:00
|
|
|
)
|
|
|
|
|
'
|
|
|
|
|
|
2009-08-19 09:45:24 +08:00
|
|
|
nested1sha1=$(cd clone3/nested1 && git rev-parse HEAD)
|
|
|
|
|
nested2sha1=$(cd clone3/nested1/nested2 && git rev-parse HEAD)
|
|
|
|
|
nested3sha1=$(cd clone3/nested1/nested2/nested3 && git rev-parse HEAD)
|
|
|
|
|
submodulesha1=$(cd clone3/nested1/nested2/nested3/submodule && git rev-parse HEAD)
|
|
|
|
|
sub1sha1=$(cd clone3/sub1 && git rev-parse HEAD)
|
|
|
|
|
sub2sha1=$(cd clone3/sub2 && git rev-parse HEAD)
|
|
|
|
|
sub3sha1=$(cd clone3/sub3 && git rev-parse HEAD)
|
2009-08-20 17:24:54 +08:00
|
|
|
sub1sha1_short=$(cd clone3/sub1 && git rev-parse --short HEAD)
|
|
|
|
|
sub2sha1_short=$(cd clone3/sub2 && git rev-parse --short HEAD)
|
2009-08-19 09:45:24 +08:00
|
|
|
|
|
|
|
|
cat > expect <<EOF
|
2020-11-19 07:44:39 +08:00
|
|
|
$nested1sha1 nested1 (heads/main)
|
|
|
|
|
$nested2sha1 nested1/nested2 (heads/main)
|
|
|
|
|
$nested3sha1 nested1/nested2/nested3 (heads/main)
|
|
|
|
|
$submodulesha1 nested1/nested2/nested3/submodule (heads/main)
|
2009-08-20 17:24:54 +08:00
|
|
|
$sub1sha1 sub1 ($sub1sha1_short)
|
|
|
|
|
$sub2sha1 sub2 ($sub2sha1_short)
|
2020-11-19 07:44:39 +08:00
|
|
|
$sub3sha1 sub3 (heads/main)
|
2009-08-19 09:45:24 +08:00
|
|
|
EOF
|
|
|
|
|
|
|
|
|
|
test_expect_success 'test "status --recursive"' '
|
|
|
|
|
(
|
|
|
|
|
cd clone3 &&
|
|
|
|
|
git submodule status --recursive > ../actual
|
|
|
|
|
) &&
|
|
|
|
|
test_cmp expect actual
|
|
|
|
|
'
|
|
|
|
|
|
2016-03-30 09:27:46 +08:00
|
|
|
cat > expect <<EOF
|
2020-11-19 07:44:39 +08:00
|
|
|
$nested1sha1 nested1 (heads/main)
|
2016-03-30 09:27:46 +08:00
|
|
|
+$nested2sha1 nested1/nested2 (file2~1)
|
2020-11-19 07:44:39 +08:00
|
|
|
$nested3sha1 nested1/nested2/nested3 (heads/main)
|
|
|
|
|
$submodulesha1 nested1/nested2/nested3/submodule (heads/main)
|
2016-03-30 09:27:46 +08:00
|
|
|
EOF
|
2010-11-03 14:26:25 +08:00
|
|
|
|
|
|
|
|
test_expect_success 'ensure "status --cached --recursive" preserves the --cached flag' '
|
|
|
|
|
(
|
|
|
|
|
cd clone3 &&
|
|
|
|
|
(
|
2012-10-27 03:13:54 +08:00
|
|
|
cd nested1/nested2 &&
|
2010-11-03 14:26:25 +08:00
|
|
|
test_commit file2
|
|
|
|
|
) &&
|
|
|
|
|
git submodule status --cached --recursive -- nested1 > ../actual
|
|
|
|
|
) &&
|
|
|
|
|
test_cmp expect actual
|
|
|
|
|
'
|
|
|
|
|
|
2016-03-30 09:27:43 +08:00
|
|
|
nested2sha1=$(git -C clone3/nested1/nested2 rev-parse HEAD)
|
|
|
|
|
|
|
|
|
|
cat > expect <<EOF
|
2020-11-19 07:44:39 +08:00
|
|
|
$nested1sha1 ../nested1 (heads/main)
|
2016-03-30 09:27:43 +08:00
|
|
|
+$nested2sha1 ../nested1/nested2 (file2)
|
2020-11-19 07:44:39 +08:00
|
|
|
$nested3sha1 ../nested1/nested2/nested3 (heads/main)
|
|
|
|
|
$submodulesha1 ../nested1/nested2/nested3/submodule (heads/main)
|
2016-03-30 09:27:43 +08:00
|
|
|
$sub1sha1 ../sub1 ($sub1sha1_short)
|
|
|
|
|
$sub2sha1 ../sub2 ($sub2sha1_short)
|
2020-11-19 07:44:39 +08:00
|
|
|
$sub3sha1 ../sub3 (heads/main)
|
2016-03-30 09:27:43 +08:00
|
|
|
EOF
|
|
|
|
|
|
|
|
|
|
test_expect_success 'test "status --recursive" from sub directory' '
|
|
|
|
|
(
|
|
|
|
|
cd clone3 &&
|
|
|
|
|
mkdir tmp && cd tmp &&
|
|
|
|
|
git submodule status --recursive > ../../actual
|
|
|
|
|
) &&
|
|
|
|
|
test_cmp expect actual
|
|
|
|
|
'
|
|
|
|
|
|
2009-08-20 07:07:43 +08:00
|
|
|
test_expect_success 'use "git clone --recursive" to checkout all submodules' '
|
|
|
|
|
git clone --recursive super clone4 &&
|
2011-08-16 05:17:46 +08:00
|
|
|
(
|
|
|
|
|
cd clone4 &&
|
|
|
|
|
git rev-parse --resolve-git-dir .git &&
|
|
|
|
|
git rev-parse --resolve-git-dir sub1/.git &&
|
|
|
|
|
git rev-parse --resolve-git-dir sub2/.git &&
|
|
|
|
|
git rev-parse --resolve-git-dir sub3/.git &&
|
|
|
|
|
git rev-parse --resolve-git-dir nested1/.git &&
|
|
|
|
|
git rev-parse --resolve-git-dir nested1/nested2/.git &&
|
|
|
|
|
git rev-parse --resolve-git-dir nested1/nested2/nested3/.git &&
|
|
|
|
|
git rev-parse --resolve-git-dir nested1/nested2/nested3/submodule/.git
|
|
|
|
|
)
|
2009-08-20 07:07:43 +08:00
|
|
|
'
|
|
|
|
|
|
2010-11-03 14:26:24 +08:00
|
|
|
test_expect_success 'test "update --recursive" with a flag with spaces' '
|
|
|
|
|
git clone super "common objects" &&
|
|
|
|
|
git clone super clone5 &&
|
|
|
|
|
(
|
|
|
|
|
cd clone5 &&
|
2011-08-16 05:17:46 +08:00
|
|
|
test_must_fail git rev-parse --resolve-git-dir d nested1/.git &&
|
2010-11-03 14:26:24 +08:00
|
|
|
git submodule update --init --recursive --reference="$(dirname "$PWD")/common objects" &&
|
2011-08-16 05:17:46 +08:00
|
|
|
git rev-parse --resolve-git-dir nested1/.git &&
|
|
|
|
|
git rev-parse --resolve-git-dir nested1/nested2/.git &&
|
|
|
|
|
git rev-parse --resolve-git-dir nested1/nested2/nested3/.git &&
|
|
|
|
|
test -f .git/modules/nested1/objects/info/alternates &&
|
|
|
|
|
test -f .git/modules/nested1/modules/nested2/objects/info/alternates &&
|
|
|
|
|
test -f .git/modules/nested1/modules/nested2/modules/nested3/objects/info/alternates
|
2010-11-03 14:26:24 +08:00
|
|
|
)
|
|
|
|
|
'
|
|
|
|
|
|
2010-11-03 14:26:25 +08:00
|
|
|
test_expect_success 'use "update --recursive nested1" to checkout all submodules rooted in nested1' '
|
|
|
|
|
git clone super clone6 &&
|
|
|
|
|
(
|
|
|
|
|
cd clone6 &&
|
2011-08-16 05:17:46 +08:00
|
|
|
test_must_fail git rev-parse --resolve-git-dir sub1/.git &&
|
|
|
|
|
test_must_fail git rev-parse --resolve-git-dir sub2/.git &&
|
|
|
|
|
test_must_fail git rev-parse --resolve-git-dir sub3/.git &&
|
|
|
|
|
test_must_fail git rev-parse --resolve-git-dir nested1/.git &&
|
2010-11-03 14:26:25 +08:00
|
|
|
git submodule update --init --recursive -- nested1 &&
|
2011-08-16 05:17:46 +08:00
|
|
|
test_must_fail git rev-parse --resolve-git-dir sub1/.git &&
|
|
|
|
|
test_must_fail git rev-parse --resolve-git-dir sub2/.git &&
|
|
|
|
|
test_must_fail git rev-parse --resolve-git-dir sub3/.git &&
|
|
|
|
|
git rev-parse --resolve-git-dir nested1/.git &&
|
|
|
|
|
git rev-parse --resolve-git-dir nested1/nested2/.git &&
|
|
|
|
|
git rev-parse --resolve-git-dir nested1/nested2/nested3/.git &&
|
|
|
|
|
git rev-parse --resolve-git-dir nested1/nested2/nested3/submodule/.git
|
2010-11-03 14:26:25 +08:00
|
|
|
)
|
|
|
|
|
'
|
|
|
|
|
|
2011-06-30 08:34:58 +08:00
|
|
|
test_expect_success 'command passed to foreach retains notion of stdin' '
|
2011-06-30 08:34:57 +08:00
|
|
|
(
|
|
|
|
|
cd super &&
|
|
|
|
|
git submodule foreach echo success >../expected &&
|
|
|
|
|
yes | git submodule foreach "read y && test \"x\$y\" = xy && echo success" >../actual
|
|
|
|
|
) &&
|
|
|
|
|
test_cmp expected actual
|
|
|
|
|
'
|
|
|
|
|
|
2011-06-30 08:34:58 +08:00
|
|
|
test_expect_success 'command passed to foreach --recursive retains notion of stdin' '
|
2011-06-30 08:34:57 +08:00
|
|
|
(
|
|
|
|
|
cd clone2 &&
|
|
|
|
|
git submodule foreach --recursive echo success >../expected &&
|
|
|
|
|
yes | git submodule foreach --recursive "read y && test \"x\$y\" = xy && echo success" >../actual
|
|
|
|
|
) &&
|
|
|
|
|
test_cmp expected actual
|
|
|
|
|
'
|
|
|
|
|
|
2013-09-27 18:23:55 +08:00
|
|
|
test_expect_success 'multi-argument command passed to foreach is not shell-evaluated twice' '
|
|
|
|
|
(
|
|
|
|
|
cd super &&
|
|
|
|
|
git submodule foreach "echo \\\"quoted\\\"" > ../expected &&
|
|
|
|
|
git submodule foreach echo \"quoted\" > ../actual
|
|
|
|
|
) &&
|
|
|
|
|
test_cmp expected actual
|
|
|
|
|
'
|
|
|
|
|
|
2019-04-12 18:08:19 +08:00
|
|
|
test_expect_success 'option-like arguments passed to foreach commands are not lost' '
|
|
|
|
|
(
|
|
|
|
|
cd super &&
|
|
|
|
|
git submodule foreach "echo be --quiet" > ../expected &&
|
|
|
|
|
git submodule foreach echo be --quiet > ../actual
|
|
|
|
|
) &&
|
|
|
|
|
grep -sq -e "--quiet" expected &&
|
|
|
|
|
test_cmp expected actual
|
|
|
|
|
'
|
|
|
|
|
|
2019-06-25 04:26:55 +08:00
|
|
|
test_expect_success 'option-like arguments passed to foreach recurse correctly' '
|
|
|
|
|
git -C clone2 submodule foreach --recursive "echo be --an-option" >expect &&
|
|
|
|
|
git -C clone2 submodule foreach --recursive echo be --an-option >actual &&
|
|
|
|
|
grep -e "--an-option" expect &&
|
|
|
|
|
test_cmp expect actual
|
|
|
|
|
'
|
|
|
|
|
|
2009-08-19 09:45:20 +08:00
|
|
|
test_done
|
