mirrors/git
1
0
Fork 0
mirror of https://github.com/git/git.git synced 2024-11-12 20:23:02 +01:00
Code Activity
git/t/t7407-submodule-foreach.sh

317 lines
9.2 KiB
Bash
Raw Normal View History

Add selftest for 'git submodule foreach' The selftest verifies that: - only checked out submodules are visited by 'git submodule foreach' - the $path, and $sha1 variables are set correctly for each submodule Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-19 03:45:20 +02: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.
'
. ./test-lib.sh
test_expect_success 'setup a submodule tree' '
echo file > file &&
git add file &&
test_tick &&
t7406 & t7407: add missing && at end of lines Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-01 23:28:27 +02:00
git commit -m upstream &&
Add selftest for 'git submodule foreach' The selftest verifies that: - only checked out submodules are visited by 'git submodule foreach' - the $path, and $sha1 variables are set correctly for each submodule Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-19 03:45:20 +02: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 &&
t7406 & t7407: add missing && at end of lines Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-01 23:28:27 +02:00
git add .gitmodules &&
Add selftest for 'git submodule foreach' The selftest verifies that: - only checked out submodules are visited by 'git submodule foreach' - the $path, and $sha1 variables are set correctly for each submodule Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-19 03:45:20 +02: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)
git-submodule foreach: Add $toplevel variable Add a $toplevel variable accessible to `git submodule foreach`, it contains the absolute path of the top level directory (where .gitmodules is). This makes it possible to e.g. read data in .gitmodules from within foreach commands. I'm using this to configure the branch names I want to track for each submodule: git submodule foreach 'git checkout $(git config --file $toplevel/.gitmodules submodule.$name.branch) && git pull' For a little history: This patch is borne out of my continuing fight of trying to have Git track the branches of submodules, not just their commits. Obviously that's not how they work (they only track commits), but I'm just interested in being able to do: git submodule foreach 'git pull' Of course that won't work because the submodule is in a disconnected head, so I first have to connect it, but connect it *to what*. For a while I was happy with this because as fate had it, it just so happened to do what I meant: git submodule foreach 'git checkout $(git describe --all --always) && git pull' But then that broke down, if there's a tag and a branch the tag will win out, and I can't git pull a branch: $ git branch -a * master remotes/origin/HEAD -> origin/master remotes/origin/master $ git tag -l release-0.0.6 $ git describe --always --all release-0.0.6 So I figured that I might as well start tracking the branches I want in .gitmodules itself: [submodule "yaml-mode"] path = yaml-mode url = git://github.com/yoshiki/yaml-mode.git branch = master So now I can just do (as stated above): git submodule foreach 'git checkout $(git config --file $toplevel/.gitmodules submodule.$name.branch) && git pull' Maybe there's a less painful way to do *that* (I'd love to hear about it). But regardless of that I think it's a good idea to be able to know what the top-level is from git submodule foreach. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-05-21 18:10:10 +02:00
pwd=$(pwd)
Add selftest for 'git submodule foreach' The selftest verifies that: - only checked out submodules are visited by 'git submodule foreach' - the $path, and $sha1 variables are set correctly for each submodule Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-19 03:45:20 +02:00
cat > expect <<EOF
Entering 'sub1'
git-submodule foreach: Add $toplevel variable Add a $toplevel variable accessible to `git submodule foreach`, it contains the absolute path of the top level directory (where .gitmodules is). This makes it possible to e.g. read data in .gitmodules from within foreach commands. I'm using this to configure the branch names I want to track for each submodule: git submodule foreach 'git checkout $(git config --file $toplevel/.gitmodules submodule.$name.branch) && git pull' For a little history: This patch is borne out of my continuing fight of trying to have Git track the branches of submodules, not just their commits. Obviously that's not how they work (they only track commits), but I'm just interested in being able to do: git submodule foreach 'git pull' Of course that won't work because the submodule is in a disconnected head, so I first have to connect it, but connect it *to what*. For a while I was happy with this because as fate had it, it just so happened to do what I meant: git submodule foreach 'git checkout $(git describe --all --always) && git pull' But then that broke down, if there's a tag and a branch the tag will win out, and I can't git pull a branch: $ git branch -a * master remotes/origin/HEAD -> origin/master remotes/origin/master $ git tag -l release-0.0.6 $ git describe --always --all release-0.0.6 So I figured that I might as well start tracking the branches I want in .gitmodules itself: [submodule "yaml-mode"] path = yaml-mode url = git://github.com/yoshiki/yaml-mode.git branch = master So now I can just do (as stated above): git submodule foreach 'git checkout $(git config --file $toplevel/.gitmodules submodule.$name.branch) && git pull' Maybe there's a less painful way to do *that* (I'd love to hear about it). But regardless of that I think it's a good idea to be able to know what the top-level is from git submodule foreach. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-05-21 18:10:10 +02:00
$pwd/clone-foo1-sub1-$sub1sha1
Add selftest for 'git submodule foreach' The selftest verifies that: - only checked out submodules are visited by 'git submodule foreach' - the $path, and $sha1 variables are set correctly for each submodule Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-19 03:45:20 +02:00
Entering 'sub3'
git-submodule foreach: Add $toplevel variable Add a $toplevel variable accessible to `git submodule foreach`, it contains the absolute path of the top level directory (where .gitmodules is). This makes it possible to e.g. read data in .gitmodules from within foreach commands. I'm using this to configure the branch names I want to track for each submodule: git submodule foreach 'git checkout $(git config --file $toplevel/.gitmodules submodule.$name.branch) && git pull' For a little history: This patch is borne out of my continuing fight of trying to have Git track the branches of submodules, not just their commits. Obviously that's not how they work (they only track commits), but I'm just interested in being able to do: git submodule foreach 'git pull' Of course that won't work because the submodule is in a disconnected head, so I first have to connect it, but connect it *to what*. For a while I was happy with this because as fate had it, it just so happened to do what I meant: git submodule foreach 'git checkout $(git describe --all --always) && git pull' But then that broke down, if there's a tag and a branch the tag will win out, and I can't git pull a branch: $ git branch -a * master remotes/origin/HEAD -> origin/master remotes/origin/master $ git tag -l release-0.0.6 $ git describe --always --all release-0.0.6 So I figured that I might as well start tracking the branches I want in .gitmodules itself: [submodule "yaml-mode"] path = yaml-mode url = git://github.com/yoshiki/yaml-mode.git branch = master So now I can just do (as stated above): git submodule foreach 'git checkout $(git config --file $toplevel/.gitmodules submodule.$name.branch) && git pull' Maybe there's a less painful way to do *that* (I'd love to hear about it). But regardless of that I think it's a good idea to be able to know what the top-level is from git submodule foreach. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-05-21 18:10:10 +02:00
$pwd/clone-foo3-sub3-$sub3sha1
Add selftest for 'git submodule foreach' The selftest verifies that: - only checked out submodules are visited by 'git submodule foreach' - the $path, and $sha1 variables are set correctly for each submodule Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-19 03:45:20 +02:00
EOF
test_expect_success 'test basic "submodule foreach" usage' '
git clone super clone &&
(
cd clone &&
git submodule update --init -- sub1 sub3 &&
git-submodule foreach: Add $toplevel variable Add a $toplevel variable accessible to `git submodule foreach`, it contains the absolute path of the top level directory (where .gitmodules is). This makes it possible to e.g. read data in .gitmodules from within foreach commands. I'm using this to configure the branch names I want to track for each submodule: git submodule foreach 'git checkout $(git config --file $toplevel/.gitmodules submodule.$name.branch) && git pull' For a little history: This patch is borne out of my continuing fight of trying to have Git track the branches of submodules, not just their commits. Obviously that's not how they work (they only track commits), but I'm just interested in being able to do: git submodule foreach 'git pull' Of course that won't work because the submodule is in a disconnected head, so I first have to connect it, but connect it *to what*. For a while I was happy with this because as fate had it, it just so happened to do what I meant: git submodule foreach 'git checkout $(git describe --all --always) && git pull' But then that broke down, if there's a tag and a branch the tag will win out, and I can't git pull a branch: $ git branch -a * master remotes/origin/HEAD -> origin/master remotes/origin/master $ git tag -l release-0.0.6 $ git describe --always --all release-0.0.6 So I figured that I might as well start tracking the branches I want in .gitmodules itself: [submodule "yaml-mode"] path = yaml-mode url = git://github.com/yoshiki/yaml-mode.git branch = master So now I can just do (as stated above): git submodule foreach 'git checkout $(git config --file $toplevel/.gitmodules submodule.$name.branch) && git pull' Maybe there's a less painful way to do *that* (I'd love to hear about it). But regardless of that I think it's a good idea to be able to know what the top-level is from git submodule foreach. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-05-21 18:10:10 +02: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"
Add selftest for 'git submodule foreach' The selftest verifies that: - only checked out submodules are visited by 'git submodule foreach' - the $path, and $sha1 variables are set correctly for each submodule Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-19 03:45:20 +02:00
) &&
i18n: git-submodule "Entering [...]" message Gettextize the "Entering [...]" message. This is explicitly tested for so we need to skip a portion of a test with test_i18ncmp. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-21 20:44:06 +02:00
test_i18ncmp expect actual
Add selftest for 'git submodule foreach' The selftest verifies that: - only checked out submodules are visited by 'git submodule foreach' - the $path, and $sha1 variables are set correctly for each submodule Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-19 03:45:20 +02:00
'
git submodule foreach: Add --recursive to recurse into nested submodules In very large and hierarchically structured projects, one may encounter nested submodules. In these situations, it is valuable to not only operate on all the submodules in the current repo (which is what is currently done by 'git submodule foreach'), but also to operate on all submodules at all levels (i.e. recursing into nested submodules as well). This patch teaches the new --recursive option to the 'git submodule foreach' command. The patch also includes documentation and selftests. Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-19 03:45:22 +02: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 &&
rev-parse: add option --resolve-git-dir <path> Check if <path> is a valid git-dir or a valid git-file that points to a valid git-dir. We want tests to be independent from the fact that a git-dir may be a git-file. Thus we changed tests to use this feature. Signed-off-by: Fredrik Gustafsson <iveqy@iveqy.com> Mentored-by: Jens Lehmann <Jens.Lehmann@web.de> Mentored-by: Heiko Voigt <hvoigt@hvoigt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-15 23:17:46 +02: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 &&
git submodule foreach: Add --recursive to recurse into nested submodules In very large and hierarchically structured projects, one may encounter nested submodules. In these situations, it is valuable to not only operate on all the submodules in the current repo (which is what is currently done by 'git submodule foreach'), but also to operate on all submodules at all levels (i.e. recursing into nested submodules as well). This patch teaches the new --recursive option to the 'git submodule foreach' command. The patch also includes documentation and selftests. Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-19 03:45:22 +02:00
git submodule update --init &&
rev-parse: add option --resolve-git-dir <path> Check if <path> is a valid git-dir or a valid git-file that points to a valid git-dir. We want tests to be independent from the fact that a git-dir may be a git-file. Thus we changed tests to use this feature. Signed-off-by: Fredrik Gustafsson <iveqy@iveqy.com> Mentored-by: Jens Lehmann <Jens.Lehmann@web.de> Mentored-by: Heiko Voigt <hvoigt@hvoigt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-15 23:17:46 +02: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 &&
git submodule foreach: Add --recursive to recurse into nested submodules In very large and hierarchically structured projects, one may encounter nested submodules. In these situations, it is valuable to not only operate on all the submodules in the current repo (which is what is currently done by 'git submodule foreach'), but also to operate on all submodules at all levels (i.e. recursing into nested submodules as well). This patch teaches the new --recursive option to the 'git submodule foreach' command. The patch also includes documentation and selftests. Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-19 03:45:22 +02:00
git submodule foreach "git submodule update --init" &&
rev-parse: add option --resolve-git-dir <path> Check if <path> is a valid git-dir or a valid git-file that points to a valid git-dir. We want tests to be independent from the fact that a git-dir may be a git-file. Thus we changed tests to use this feature. Signed-off-by: Fredrik Gustafsson <iveqy@iveqy.com> Mentored-by: Jens Lehmann <Jens.Lehmann@web.de> Mentored-by: Heiko Voigt <hvoigt@hvoigt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-15 23:17:46 +02:00
git rev-parse --resolve-git-dir nested1/nested1/nested2/.git
test_must_fail git rev-parse --resolve-git-dir nested1/nested2/nested3/.git
git submodule foreach: Add --recursive to recurse into nested submodules In very large and hierarchically structured projects, one may encounter nested submodules. In these situations, it is valuable to not only operate on all the submodules in the current repo (which is what is currently done by 'git submodule foreach'), but also to operate on all submodules at all levels (i.e. recursing into nested submodules as well). This patch teaches the new --recursive option to the 'git submodule foreach' command. The patch also includes documentation and selftests. Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-19 03:45:22 +02:00
)
'
test_expect_success 'use "foreach --recursive" to checkout all submodules' '
(
cd clone2 &&
git submodule foreach --recursive "git submodule update --init" &&
rev-parse: add option --resolve-git-dir <path> Check if <path> is a valid git-dir or a valid git-file that points to a valid git-dir. We want tests to be independent from the fact that a git-dir may be a git-file. Thus we changed tests to use this feature. Signed-off-by: Fredrik Gustafsson <iveqy@iveqy.com> Mentored-by: Jens Lehmann <Jens.Lehmann@web.de> Mentored-by: Heiko Voigt <hvoigt@hvoigt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-15 23:17:46 +02:00
git rev-parse --resolve-git-dir nested1/nested2/nested3/.git &&
git rev-parse --resolve-git-dir nested1/nested2/nested3/submodule/.git
git submodule foreach: Add --recursive to recurse into nested submodules In very large and hierarchically structured projects, one may encounter nested submodules. In these situations, it is valuable to not only operate on all the submodules in the current repo (which is what is currently done by 'git submodule foreach'), but also to operate on all submodules at all levels (i.e. recursing into nested submodules as well). This patch teaches the new --recursive option to the 'git submodule foreach' command. The patch also includes documentation and selftests. Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-19 03:45:22 +02: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
) &&
i18n: git-submodule "Entering [...]" message Gettextize the "Entering [...]" message. This is explicitly tested for so we need to skip a portion of a test with test_i18ncmp. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-21 20:44:06 +02:00
test_i18ncmp expect actual
git submodule foreach: Add --recursive to recurse into nested submodules In very large and hierarchically structured projects, one may encounter nested submodules. In these situations, it is valuable to not only operate on all the submodules in the current repo (which is what is currently done by 'git submodule foreach'), but also to operate on all submodules at all levels (i.e. recursing into nested submodules as well). This patch teaches the new --recursive option to the 'git submodule foreach' command. The patch also includes documentation and selftests. Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-19 03:45:22 +02: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
'
git submodule update: Introduce --recursive to update nested submodules In very large and hierarchically structured projects, one may encounter nested submodules. In these situations, it is valuable to not only update the submodules in the current repo (which is what is currently done by 'git submodule update'), but also to operate on all submodules at all levels (i.e. recursing into nested submodules as well). This patch teaches the new --recursive option to the 'git submodule update' command. The patch also includes documentation and selftests. Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-19 03:45:23 +02:00
test_expect_success 'use "update --recursive" to checkout all submodules' '
git clone super clone3 &&
(
cd clone3 &&
rev-parse: add option --resolve-git-dir <path> Check if <path> is a valid git-dir or a valid git-file that points to a valid git-dir. We want tests to be independent from the fact that a git-dir may be a git-file. Thus we changed tests to use this feature. Signed-off-by: Fredrik Gustafsson <iveqy@iveqy.com> Mentored-by: Jens Lehmann <Jens.Lehmann@web.de> Mentored-by: Heiko Voigt <hvoigt@hvoigt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-15 23:17:46 +02: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 &&
git submodule update: Introduce --recursive to update nested submodules In very large and hierarchically structured projects, one may encounter nested submodules. In these situations, it is valuable to not only update the submodules in the current repo (which is what is currently done by 'git submodule update'), but also to operate on all submodules at all levels (i.e. recursing into nested submodules as well). This patch teaches the new --recursive option to the 'git submodule update' command. The patch also includes documentation and selftests. Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-19 03:45:23 +02:00
git submodule update --init --recursive &&
rev-parse: add option --resolve-git-dir <path> Check if <path> is a valid git-dir or a valid git-file that points to a valid git-dir. We want tests to be independent from the fact that a git-dir may be a git-file. Thus we changed tests to use this feature. Signed-off-by: Fredrik Gustafsson <iveqy@iveqy.com> Mentored-by: Jens Lehmann <Jens.Lehmann@web.de> Mentored-by: Heiko Voigt <hvoigt@hvoigt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-15 23:17:46 +02: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
git submodule update: Introduce --recursive to update nested submodules In very large and hierarchically structured projects, one may encounter nested submodules. In these situations, it is valuable to not only update the submodules in the current repo (which is what is currently done by 'git submodule update'), but also to operate on all submodules at all levels (i.e. recursing into nested submodules as well). This patch teaches the new --recursive option to the 'git submodule update' command. The patch also includes documentation and selftests. Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-19 03:45:23 +02:00
)
'
git submodule status: Add --recursive to recurse into nested submodules In very large and hierarchically structured projects, one may encounter nested submodules. In these situations, it is valuable to not only show status for all the submodules in the current repo (which is what is currently done by 'git submodule status'), but also to show status for all submodules at all levels (i.e. recursing into nested submodules as well). This patch teaches the new --recursive option to the 'git submodule status' command. The patch also includes documentation and selftests. Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-19 03:45:24 +02: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)
t7407: Use 'rev-parse --short' rather than bash's substring expansion notation The substring expansion notation is a bashism that we have not so far adopted. Use 'git rev-parse --short' instead, as this also handles the case where the unique abbreviation is longer than 7 characters. Also fix the typo; the object name for submodule #2 was copied from submodule #1's by mistake. Suggested-by: Brandon Casey <casey@nrlssc.navy.mil> Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-20 11:24:54 +02:00
sub1sha1_short=$(cd clone3/sub1 && git rev-parse --short HEAD)
sub2sha1_short=$(cd clone3/sub2 && git rev-parse --short HEAD)
git submodule status: Add --recursive to recurse into nested submodules In very large and hierarchically structured projects, one may encounter nested submodules. In these situations, it is valuable to not only show status for all the submodules in the current repo (which is what is currently done by 'git submodule status'), but also to show status for all submodules at all levels (i.e. recursing into nested submodules as well). This patch teaches the new --recursive option to the 'git submodule status' command. The patch also includes documentation and selftests. Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-19 03:45:24 +02:00
cat > expect <<EOF
$nested1sha1 nested1 (heads/master)
$nested2sha1 nested1/nested2 (heads/master)
$nested3sha1 nested1/nested2/nested3 (heads/master)
$submodulesha1 nested1/nested2/nested3/submodule (heads/master)
t7407: Use 'rev-parse --short' rather than bash's substring expansion notation The substring expansion notation is a bashism that we have not so far adopted. Use 'git rev-parse --short' instead, as this also handles the case where the unique abbreviation is longer than 7 characters. Also fix the typo; the object name for submodule #2 was copied from submodule #1's by mistake. Suggested-by: Brandon Casey <casey@nrlssc.navy.mil> Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-20 11:24:54 +02:00
$sub1sha1 sub1 ($sub1sha1_short)
$sub2sha1 sub2 ($sub2sha1_short)
git submodule status: Add --recursive to recurse into nested submodules In very large and hierarchically structured projects, one may encounter nested submodules. In these situations, it is valuable to not only show status for all the submodules in the current repo (which is what is currently done by 'git submodule status'), but also to show status for all submodules at all levels (i.e. recursing into nested submodules as well). This patch teaches the new --recursive option to the 'git submodule status' command. The patch also includes documentation and selftests. Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-19 03:45:24 +02:00
$sub3sha1 sub3 (heads/master)
EOF
test_expect_success 'test "status --recursive"' '
(
cd clone3 &&
git submodule status --recursive > ../actual
) &&
test_cmp expect actual
'
submodule: only preserve flags across recursive status/update invocations Recursive invocations of submodule update/status preserve all arguments, so executing git submodule update --recursive -- foo attempts to recursively update a submodule named "foo". Naturally, this fails as one cannot have an infinitely-deep stack of submodules each containing a submodule named "foo". The desired behavior is instead to update foo and then recursively update all submodules inside of foo. This commit accomplishes that by only saving the flags for use in the recursive invocation. Signed-off-by: Kevin Ballard <kevin@sb.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-11-03 07:26:25 +01:00
sed -e "/nested1 /s/.*/+$nested1sha1 nested1 (file2~1)/;/sub[1-3]/d" < expect > expect2
mv -f expect2 expect
test_expect_success 'ensure "status --cached --recursive" preserves the --cached flag' '
(
cd clone3 &&
(
cd nested1 &&
test_commit file2
) &&
git submodule status --cached --recursive -- nested1 > ../actual
) &&
t7407: fix line endings for mingw build Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-02-03 16:31:44 +01:00
if test_have_prereq MINGW
then
dos2unix actual
fi &&
submodule: only preserve flags across recursive status/update invocations Recursive invocations of submodule update/status preserve all arguments, so executing git submodule update --recursive -- foo attempts to recursively update a submodule named "foo". Naturally, this fails as one cannot have an infinitely-deep stack of submodules each containing a submodule named "foo". The desired behavior is instead to update foo and then recursively update all submodules inside of foo. This commit accomplishes that by only saving the flags for use in the recursive invocation. Signed-off-by: Kevin Ballard <kevin@sb.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-11-03 07:26:25 +01:00
test_cmp expect actual
'
git clone: Add --recursive to automatically checkout (nested) submodules Many projects using submodules expect all submodules to be checked out in order to build/work correctly. A common command sequence for developers on such projects is: git clone url/to/project cd project git submodule update --init (--recursive) This patch introduces the --recursive option to git-clone. The new option causes git-clone to recursively clone and checkout all submodules of the cloned project. Hence, the above command sequence can be reduced to: git clone --recursive url/to/project --recursive is ignored if no checkout is done by the git-clone. The patch also includes documentation and a selftest. Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-20 01:07:43 +02:00
test_expect_success 'use "git clone --recursive" to checkout all submodules' '
git clone --recursive super clone4 &&
rev-parse: add option --resolve-git-dir <path> Check if <path> is a valid git-dir or a valid git-file that points to a valid git-dir. We want tests to be independent from the fact that a git-dir may be a git-file. Thus we changed tests to use this feature. Signed-off-by: Fredrik Gustafsson <iveqy@iveqy.com> Mentored-by: Jens Lehmann <Jens.Lehmann@web.de> Mentored-by: Heiko Voigt <hvoigt@hvoigt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-15 23:17:46 +02: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
)
git clone: Add --recursive to automatically checkout (nested) submodules Many projects using submodules expect all submodules to be checked out in order to build/work correctly. A common command sequence for developers on such projects is: git clone url/to/project cd project git submodule update --init (--recursive) This patch introduces the --recursive option to git-clone. The new option causes git-clone to recursively clone and checkout all submodules of the cloned project. Hence, the above command sequence can be reduced to: git clone --recursive url/to/project --recursive is ignored if no checkout is done by the git-clone. The patch also includes documentation and a selftest. Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-20 01:07:43 +02:00
'
submodule: preserve all arguments exactly when recursing Shell variables only hold strings, not lists of parameters, so $orig_args after orig_args="$@" fails to remember where each parameter starts and ends, if some include whitespace. So git submodule update \ --reference='/var/lib/common objects.git' \ --recursive --init becomes git submodule update --reference=/var/lib/common \ objects.git --recursive --init in the inner repositories. Use "git rev-parse --sq-quote" to save parameters in quoted form ready for evaluation by the shell, avoiding this problem. Helped-By: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Kevin Ballard <kevin@sb.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-11-03 07:26:24 +01:00
test_expect_success 'test "update --recursive" with a flag with spaces' '
git clone super "common objects" &&
git clone super clone5 &&
(
cd clone5 &&
rev-parse: add option --resolve-git-dir <path> Check if <path> is a valid git-dir or a valid git-file that points to a valid git-dir. We want tests to be independent from the fact that a git-dir may be a git-file. Thus we changed tests to use this feature. Signed-off-by: Fredrik Gustafsson <iveqy@iveqy.com> Mentored-by: Jens Lehmann <Jens.Lehmann@web.de> Mentored-by: Heiko Voigt <hvoigt@hvoigt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-15 23:17:46 +02:00
test_must_fail git rev-parse --resolve-git-dir d nested1/.git &&
submodule: preserve all arguments exactly when recursing Shell variables only hold strings, not lists of parameters, so $orig_args after orig_args="$@" fails to remember where each parameter starts and ends, if some include whitespace. So git submodule update \ --reference='/var/lib/common objects.git' \ --recursive --init becomes git submodule update --reference=/var/lib/common \ objects.git --recursive --init in the inner repositories. Use "git rev-parse --sq-quote" to save parameters in quoted form ready for evaluation by the shell, avoiding this problem. Helped-By: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Kevin Ballard <kevin@sb.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-11-03 07:26:24 +01:00
git submodule update --init --recursive --reference="$(dirname "$PWD")/common objects" &&
rev-parse: add option --resolve-git-dir <path> Check if <path> is a valid git-dir or a valid git-file that points to a valid git-dir. We want tests to be independent from the fact that a git-dir may be a git-file. Thus we changed tests to use this feature. Signed-off-by: Fredrik Gustafsson <iveqy@iveqy.com> Mentored-by: Jens Lehmann <Jens.Lehmann@web.de> Mentored-by: Heiko Voigt <hvoigt@hvoigt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-15 23:17:46 +02: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
submodule: preserve all arguments exactly when recursing Shell variables only hold strings, not lists of parameters, so $orig_args after orig_args="$@" fails to remember where each parameter starts and ends, if some include whitespace. So git submodule update \ --reference='/var/lib/common objects.git' \ --recursive --init becomes git submodule update --reference=/var/lib/common \ objects.git --recursive --init in the inner repositories. Use "git rev-parse --sq-quote" to save parameters in quoted form ready for evaluation by the shell, avoiding this problem. Helped-By: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Kevin Ballard <kevin@sb.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-11-03 07:26:24 +01:00
)
'
submodule: only preserve flags across recursive status/update invocations Recursive invocations of submodule update/status preserve all arguments, so executing git submodule update --recursive -- foo attempts to recursively update a submodule named "foo". Naturally, this fails as one cannot have an infinitely-deep stack of submodules each containing a submodule named "foo". The desired behavior is instead to update foo and then recursively update all submodules inside of foo. This commit accomplishes that by only saving the flags for use in the recursive invocation. Signed-off-by: Kevin Ballard <kevin@sb.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-11-03 07:26:25 +01:00
test_expect_success 'use "update --recursive nested1" to checkout all submodules rooted in nested1' '
git clone super clone6 &&
(
cd clone6 &&
rev-parse: add option --resolve-git-dir <path> Check if <path> is a valid git-dir or a valid git-file that points to a valid git-dir. We want tests to be independent from the fact that a git-dir may be a git-file. Thus we changed tests to use this feature. Signed-off-by: Fredrik Gustafsson <iveqy@iveqy.com> Mentored-by: Jens Lehmann <Jens.Lehmann@web.de> Mentored-by: Heiko Voigt <hvoigt@hvoigt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-15 23:17:46 +02: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 &&
submodule: only preserve flags across recursive status/update invocations Recursive invocations of submodule update/status preserve all arguments, so executing git submodule update --recursive -- foo attempts to recursively update a submodule named "foo". Naturally, this fails as one cannot have an infinitely-deep stack of submodules each containing a submodule named "foo". The desired behavior is instead to update foo and then recursively update all submodules inside of foo. This commit accomplishes that by only saving the flags for use in the recursive invocation. Signed-off-by: Kevin Ballard <kevin@sb.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-11-03 07:26:25 +01:00
git submodule update --init --recursive -- nested1 &&
rev-parse: add option --resolve-git-dir <path> Check if <path> is a valid git-dir or a valid git-file that points to a valid git-dir. We want tests to be independent from the fact that a git-dir may be a git-file. Thus we changed tests to use this feature. Signed-off-by: Fredrik Gustafsson <iveqy@iveqy.com> Mentored-by: Jens Lehmann <Jens.Lehmann@web.de> Mentored-by: Heiko Voigt <hvoigt@hvoigt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-15 23:17:46 +02: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
submodule: only preserve flags across recursive status/update invocations Recursive invocations of submodule update/status preserve all arguments, so executing git submodule update --recursive -- foo attempts to recursively update a submodule named "foo". Naturally, this fails as one cannot have an infinitely-deep stack of submodules each containing a submodule named "foo". The desired behavior is instead to update foo and then recursively update all submodules inside of foo. This commit accomplishes that by only saving the flags for use in the recursive invocation. Signed-off-by: Kevin Ballard <kevin@sb.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-11-03 07:26:25 +01:00
)
'
git-submodule.sh: preserve stdin for the command spawned by foreach The user-supplied command spawned by 'submodule foreach' loses its connection to the original standard input. Instead, it is connected to the output of a pipe within the git-submodule script. The user-supplied command supplied to 'submodule foreach' is spawned within a while loop which is being piped into. Due to the way shells implement piping output to a while loop, a subshell is created with its standard input attached to the output of the pipe. This results in all of the commands executed within the while loop to have their stdins modified in the same way, including the user-supplied command. This can cause a problem if the command requires reading from stdin or if it changes its behavior based on whether stdin is a tty or not. For example, this problem was noticed when trying to execute the following: git submodule foreach git shortlog --since=two.weeks.ago which printed a message about entering the first submodule and produced no further output and exited with a status of zero. In this case, shortlog detected that it was not connected to a tty, and since no revision was supplied as an argument, it attempted to read the list of revisions from standard input. Instead, it slurped up the list of submodules that was being piped to the enclosing while loop and caused that loop to end early without processing the remaining submodules. Work around this behavior by saving the original standard input file descriptor before the while loop, and restoring it when spawning the user-supplied command. This fixes the tests in t7407. Signed-off-by: Brandon Casey <drafnel@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-06-30 02:34:58 +02:00
test_expect_success 'command passed to foreach retains notion of stdin' '
t/t7407: demonstrate that the command called by 'submodule foreach' loses stdin The user-supplied command spawned by 'submodule foreach' loses its connection to the original standard input. Instead, it is connected to the output of a pipe within the git-submodule script. This can cause a problem if the command requires reading from stdin or if it changes its behavior based on whether stdin is a tty or not (e.g. git shortlog). Demonstrate this flaw. Signed-off-by: Brandon Casey <drafnel@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-06-30 02:34:57 +02: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
'
git-submodule.sh: preserve stdin for the command spawned by foreach The user-supplied command spawned by 'submodule foreach' loses its connection to the original standard input. Instead, it is connected to the output of a pipe within the git-submodule script. The user-supplied command supplied to 'submodule foreach' is spawned within a while loop which is being piped into. Due to the way shells implement piping output to a while loop, a subshell is created with its standard input attached to the output of the pipe. This results in all of the commands executed within the while loop to have their stdins modified in the same way, including the user-supplied command. This can cause a problem if the command requires reading from stdin or if it changes its behavior based on whether stdin is a tty or not. For example, this problem was noticed when trying to execute the following: git submodule foreach git shortlog --since=two.weeks.ago which printed a message about entering the first submodule and produced no further output and exited with a status of zero. In this case, shortlog detected that it was not connected to a tty, and since no revision was supplied as an argument, it attempted to read the list of revisions from standard input. Instead, it slurped up the list of submodules that was being piped to the enclosing while loop and caused that loop to end early without processing the remaining submodules. Work around this behavior by saving the original standard input file descriptor before the while loop, and restoring it when spawning the user-supplied command. This fixes the tests in t7407. Signed-off-by: Brandon Casey <drafnel@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-06-30 02:34:58 +02:00
test_expect_success 'command passed to foreach --recursive retains notion of stdin' '
t/t7407: demonstrate that the command called by 'submodule foreach' loses stdin The user-supplied command spawned by 'submodule foreach' loses its connection to the original standard input. Instead, it is connected to the output of a pipe within the git-submodule script. This can cause a problem if the command requires reading from stdin or if it changes its behavior based on whether stdin is a tty or not (e.g. git shortlog). Demonstrate this flaw. Signed-off-by: Brandon Casey <drafnel@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-06-30 02:34:57 +02: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
'
Add selftest for 'git submodule foreach' The selftest verifies that: - only checked out submodules are visited by 'git submodule foreach' - the $path, and $sha1 variables are set correctly for each submodule Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-19 03:45:20 +02:00
test_done
Copy permalink