summaryrefslogtreecommitdiff
path: root/t/t7407-submodule-foreach.sh
AgeCommit message (Collapse)AuthorFilesLines
2021-02-10tests: remove most uses of test_i18ncmpLibravatar Ævar Arnfjörð Bjarmason1-5/+5
As a follow-up to d162b25f956 (tests: remove support for GIT_TEST_GETTEXT_POISON, 2021-01-20) remove most uses of test_i18ncmp via a simple s/test_i18ncmp/test_cmp/g search-replacement. I'm leaving t6300-for-each-ref.sh out due to a conflict with in-flight changes between "master" and "seen", as well as the prerequisite itself due to other changes between "master" and "next/seen" which add new test_i18ncmp uses. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-19t7[0-4]*: adjust the references to the default branch name "main"Libravatar Johannes Schindelin1-13/+13
Carefully excluding t7064, which sees independent development elsewhere at the time of writing, we use `main` as the default branch name in t7[0-4]*. This trick was performed via $ (cd t && sed -i -e 's/master/main/g' -e 's/MASTER/MAIN/g' \ -e 's/Master/Main/g' -- t7[0-4]*.sh && git checkout HEAD -- t7064\*) This allows us to define `GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=main` for those tests. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-19tests: mark tests relying on the current default for `init.defaultBranch`Libravatar Johannes Schindelin1-0/+3
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>
2019-07-09Merge branch 'ms/submodule-foreach-fix'Libravatar Junio C Hamano1-0/+7
"git submodule foreach" did not protect command line options passed to the command to be run in each submodule correctly, when the "--recursive" option was in use. * ms/submodule-foreach-fix: submodule foreach: fix recursion of options
2019-06-25submodule foreach: fix recursion of optionsLibravatar Morian Sonnet1-0/+7
Calling git submodule foreach --recursive <subcommand> --<option> leads to an error stating that the option --<option> is unknown to submodule--helper. That is of course only, when <option> is not a valid option for git submodule foreach. The reason for this is, that above call is internally translated into a call to submodule--helper: git submodule--helper foreach --recursive \ -- <subcommand> --<option> This call starts by executing the subcommand with its option inside the first level submodule and continues by calling the next iteration of the submodule foreach call git --super-prefix <submodulepath> submodule--helper \ foreach --recursive <subcommand> --<option> inside the first level submodule. Note that the double dash in front of the subcommand is missing. This problem starts to arise only recently, as the PARSE_OPT_KEEP_UNKNOWN flag for the argument parsing of git submodule foreach was removed in commit a282f5a906. Hence, the unknown option is complained about now, as the argument parsing is not properly ended by the double dash. This commit fixes the problem by adding the double dash in front of the subcommand during the recursion. Signed-off-by: Morian Sonnet <moriansonnet@googlemail.com> Acked-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-04-15submodule foreach: fix "<command> --quiet" not being respectedLibravatar Nguyễn Thái Ngọc Duy1-0/+10
Robin reported that git submodule foreach --quiet git pull --quiet origin is not really quiet anymore [1]. "git pull" behaves as if --quiet is not given. This happens because parseopt in submodule--helper will try to parse both --quiet options as if they are foreach's options, not git-pull's. The parsed options are removed from the command line. So when we do pull later, we execute just this git pull origin When calling submodule helper, adding "--" in front of "git pull" will stop parseopt for parsing options that do not really belong to submodule--helper foreach. PARSE_OPT_KEEP_UNKNOWN is removed as a safety measure. parseopt should never see unknown options or something has gone wrong. There are also a couple usage string update while I'm looking at them. While at it, I also add "--" to other subcommands that pass "$@" to submodule--helper. "$@" in these cases are paths and less likely to be --something-like-this. But the point still stands, git-submodule has parsed and classified what are options, what are paths. submodule--helper should never consider paths passed by git-submodule to be options even if they look like one. The test case is also contributed by Robin. [1] it should be quiet before fc1b9243cd (submodule: port submodule subcommand 'foreach' from shell to C, 2018-05-10) because parseopt can't accidentally eat options then. Reported-by: Robin H. Johnson <robbat2@gentoo.org> Tested-by: Robin H. Johnson <robbat2@gentoo.org> Signed-off-by: Robin H. Johnson <robbat2@gentoo.org> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-09submodule foreach: document variable '$displaypath'Libravatar Prathamesh Chavan1-11/+11
It was observed that the variable '$displaypath' was accessible but undocumented. Hence, document it. Discussed-with: Ramsay Jones <ramsay@ramsayjones.plus.com> Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Prathamesh Chavan <pc44800@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-09submodule foreach: correct '$path' in nested submodules from a subdirectoryLibravatar Prathamesh Chavan1-2/+34
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>
2016-03-30t7407: make expectation as clear as possibleLibravatar Stefan Beller1-2/+6
Not everyone (including me) grasps the sed expression in a split second as they would grasp the 4 lines printed as is. Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-03-30submodule status: correct path handling in recursive submodulesLibravatar Stefan Beller1-0/+21
The new test which is a replica of the previous test except that it executes from a sub directory. Prior to this patch the test failed by having too many '../' prefixed: --- expect 2016-03-29 19:02:33.087336115 +0000 +++ actual 2016-03-29 19:02:33.359343311 +0000 @@ -1,7 +1,7 @@ b23f134787d96fae589a6b76da41f4db112fc8db ../nested1 (heads/master) -+25d56d1ddfb35c3e91ff7d8f12331c2e53147dcc ../nested1/nested2 (file2) - 5ec83512b76a0b8170b899f8e643913c3e9b72d9 ../nested1/nested2/nested3 (heads/master) - 509f622a4f36a3e472affcf28fa959174f3dd5b5 ../nested1/nested2/nested3/submodule (heads/master) ++25d56d1ddfb35c3e91ff7d8f12331c2e53147dcc ../../nested1/nested2 (file2) + 5ec83512b76a0b8170b899f8e643913c3e9b72d9 ../../../nested1/nested2/nested3 (heads/master) + 509f622a4f36a3e472affcf28fa959174f3dd5b5 ../../../../nested1/nested2/nested3/submodule (heads/master) 0c90624ab7f1aaa301d3bb79f60dcfed1ec4897f ../sub1 (0c90624) 0c90624ab7f1aaa301d3bb79f60dcfed1ec4897f ../sub2 (0c90624) 509f622a4f36a3e472affcf28fa959174f3dd5b5 ../sub3 (heads/master) The path code in question: displaypath=$(relative_path "$prefix$sm_path") prefix=$displaypath if recursive: eval cmd_status That way we change `prefix` each iteration to contain another '../', because of the the relative_path computation is done on an already computed relative path. We must call relative_path exactly once with `wt_prefix` non empty. Further calls in recursive instances to to calculate the displaypath already incorporate the correct prefix from before. Fix the issue by clearing `wt_prefix` in recursive calls. Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-03-30submodule foreach: correct path display in recursive submodulesLibravatar Stefan Beller1-0/+20
The `prefix` was put in front of the display path unconditionally. This is wrong as any relative path computation would need to be at the front, so include the prefix into the display path. The new test replicates the previous test with the difference of executing from a sub directory. By executing from a sub directory all we would expect all displayed paths to be prefixed by '../'. Prior to this patch the test would report Entering 'nested1/nested2/../nested3' instead of the expected Entering '../nested1/nested2/nested3' Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-05Merge branch 'ak/submodule-foreach-quoting'Libravatar Junio C Hamano1-0/+9
A behavior change, but a worthwhile one: "git submodule foreach" was treating its arguments as part of a single command to be concatenated and passed to a shell, making writing buggy scripts too easy. This patch preserves the old "just pass it to the shell" behavior when a single argument is passed to 'git submodule foreach' and moves to a new "skip the shell and use the arguments passed unmolested" behavior when more than one argument is passed. The old behavior (always concatenating and passing to the shell) was similar to the 'ssh' command, while the new behavior (switching on the number of arguments) is what 'xterm -e' does. May need more thought to make sure this change is advertised well so that scripts that used multiple arguments but added their own extra layer of quoting are not broken. * ak/submodule-foreach-quoting: submodule foreach: skip eval for more than one argument
2013-10-28tests: undo special treatment of CRLF for WindowsLibravatar Johannes Sixt1-4/+0
Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-27submodule foreach: skip eval for more than one argumentLibravatar Anders Kaseorg1-0/+9
'eval "$@"' creates an extra layer of shell interpretation, which is probably not expected by a user who passes multiple arguments to git submodule foreach: $ git grep "'" [searches for single quotes] $ git submodule foreach git grep "'" Entering '[submodule]' /usr/lib/git-core/git-submodule: 1: eval: Syntax error: Unterminated quoted string Stopping at '[submodule]'; script returned non-zero status. To fix this, if the user passes more than one argument, execute "$@" directly instead of passing it to eval. Examples: * Typical usage when adding an extra level of quoting is to pass a single argument representing the entire command to be passed to the shell. This doesn't change that. * One can imagine someone feeding untrusted input as an argument: git submodule foreach git grep "$variable" That currently results in a nonobvious shell code injection vulnerability. Executing the command named by the arguments directly, as in this patch, fixes it. Signed-off-by: Anders Kaseorg <andersk@mit.edu> Acked-by: Johan Herland <johan@herland.net> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
2013-08-09t/t7407: fix two typos in submodule testsLibravatar Phil Hord1-1/+1
In t/t7407-submodule-foreach.sh there is a typo in one of the path names given for a test step. The correct path is nested1/nested2/.git, but nested1/nested1/nested2/.git is given instead. The typo is hidden because this line also accidentally omits the && chain operator. The omitted chain also means the return values of all the previous commands in this test are also being ignored. Fix the path and add the chain operator so the entire test sequence can be properly validated. Signed-off-by: Phil Hord <hordp@cisco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-17submodule: drop the top-level requirementLibravatar John Keeping1-0/+16
Use the new rev-parse --prefix option to process all paths given to the submodule command, dropping the requirement that it be run from the top-level of the repository. Since the interpretation of a relative submodule URL depends on whether or not "remote.origin.url" is configured, explicitly block relative URLs in "git submodule add" when not at the top level of the working tree. Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-29t7407: Fix recursive submodule testLibravatar Phil Hord1-2/+2
A test in t7404-submodule-foreach purports to test that the --cached flag is properly noticed by --recursive calls to the foreach command as it descends into nested submodules. However, the test really does not perform this test since the change it looks for is in a top-level submodule handled by the first invocation of the command. To properly test for the flag being passed to recursive invocations, the change must be buried deeper in the hierarchy. Move the change one level deeper so it properly verifies the recursive machinery of the 'git submodule status' command. Signed-off-by: Phil Hord <hordp@cisco.com> Signed-off-by: Jeff King <peff@peff.net>
2011-08-16rev-parse: add option --resolve-git-dir <path>Libravatar Fredrik Gustafsson1-50/+53
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-07-13Merge branch 'bc/submodule-foreach-stdin-fix-1.7.4'Libravatar Junio C Hamano1-0/+18
* bc/submodule-foreach-stdin-fix-1.7.4: git-submodule.sh: preserve stdin for the command spawned by foreach t/t7407: demonstrate that the command called by 'submodule foreach' loses stdin Conflicts: git-submodule.sh
2011-06-29git-submodule.sh: preserve stdin for the command spawned by foreachLibravatar Brandon Casey1-2/+2
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-29t/t7407: demonstrate that the command called by 'submodule foreach' loses stdinLibravatar Brandon Casey1-0/+18
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-05-21i18n: git-submodule "Entering [...]" messageLibravatar Ævar Arnfjörð Bjarmason1-2/+2
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-02-07t7407: fix line endings for mingw buildLibravatar Pat Thoyts1-0/+4
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-11-03submodule: only preserve flags across recursive status/update invocationsLibravatar Kevin Ballard1-0/+34
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-03submodule: preserve all arguments exactly when recursingLibravatar Kevin Ballard1-0/+16
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-09-03t7406 & t7407: add missing && at end of linesLibravatar Jens Lehmann1-2/+2
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-05-25git-submodule foreach: Add $toplevel variableLibravatar Ævar Arnfjörð Bjarmason1-3/+7
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>
2009-08-20git clone: Add --recursive to automatically checkout (nested) submodulesLibravatar Johan Herland1-0/+12
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-20t7407: Use 'rev-parse --short' rather than bash's substring expansion notationLibravatar Johan Herland1-2/+4
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-18git submodule status: Add --recursive to recurse into nested submodulesLibravatar Johan Herland1-0/+26
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-18git submodule update: Introduce --recursive to update nested submodulesLibravatar Johan Herland1-0/+19
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-18git submodule foreach: Add --recursive to recurse into nested submodulesLibravatar Johan Herland1-0/+99
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-18git submodule foreach: test access to submodule name as '$name'Libravatar Johan Herland1-3/+3
Add verification of the behaviour of '$name' to the git submodule foreach selftest. Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-18Add selftest for 'git submodule foreach'Libravatar Johan Herland1-0/+79
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>