summaryrefslogtreecommitdiff
path: root/git-submodule.sh
AgeCommit message (Collapse)AuthorFilesLines
2014-01-17Merge branch 'fp/submodule-checkout-mode'Libravatar Junio C Hamano1-1/+12
"submodule.*.update=checkout", when propagated from .gitmodules to .git/config, turned into a "submodule.*.update=none", which did not make much sense. * fp/submodule-checkout-mode: git-submodule.sh: 'checkout' is a valid update mode
2014-01-07git-submodule.sh: 'checkout' is a valid update modeLibravatar Francesco Pretto1-1/+12
'checkout' is documented as one of the valid values for the 'submodule.<name>.update' variable, and in a repository with the variable set to 'checkout', "git submodule update" command does update using the 'checkout' mode. However, it has been an accident that the implementation works this way; any unknown value would trigger the same codepath and update using the 'checkout' mode. Explicitly list 'checkout' as one of the known update modes, and error out when an unknown update mode is used. Teach the codepath that initializes the configuration variable from an in-tree .gitmodules that 'checkout' is one of the valid values. The code since ac1fbbda (submodule: do not copy unknown update mode from .gitmodules, 2013-12-02) used to treat the value 'checkout' as unknown and mapped it to 'none', which made little sense. With this change, 'checkout' specified in .gitmodules will stay to be 'checkout'. Signed-off-by: Francesco Pretto <ceztko@gmail.com> Signed-off-by: Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-05Merge branch 'jl/submodule-update-retire-orig-flags'Libravatar Junio C Hamano1-4/+1
Code clean-up. * jl/submodule-update-retire-orig-flags: submodule update: remove unnecessary orig_flags variable
2013-12-05Merge branch 'jk/replace-perl-in-built-scripts'Libravatar Junio C Hamano1-1/+1
* jk/replace-perl-in-built-scripts: use @@PERL@@ in built scripts
2013-12-05Merge branch 'ak/submodule-foreach-quoting'Libravatar Junio C Hamano1-1/+6
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-12-02Sync with 1.8.4.5Libravatar Junio C Hamano1-5/+15
2013-12-02submodule: do not copy unknown update mode from .gitmodulesLibravatar Junio C Hamano1-5/+15
When submodule.$name.update is given as hint from the upstream in the .gitmodules file, we used to blindly copy it to .git/config, unless there already is a value defined for the submodule. However, there is no reason to expect that the update mode hinted by the upstream is available in the version of Git the user is using, and a really custom "!cmd" prepared by an upstream person running on Linux may not even be available to a user on Windows. It is simply irresponsible to copy the setting blindly and to attempt to use it during a later "submodule update" without validating it first. Just show the suggested value to the diagnostic output, and set the value to 'none' in the configuration, if it is not one of the ones that are known to be supported by this version of Git. Helped-by: Jens Lehmann <Jens.Lehmann@web.de> Helped-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-11-11submodule update: remove unnecessary orig_flags variableLibravatar Jens Lehmann1-4/+1
cmd_update() in the submodule script tries to preserve the options given on the command line in the "orig_flags" variable to pass them on into the recursion when the '--recursive' option is given. But this isn't necessary because all the variables set by the options will be seen in the recursion too as that is achieved by executing "eval cmd_update". The same has already been done for cmd_status() in e15bec0ec, so let's clean up cmd_update() likewise. Also add a test to make sure that a submodule name given on the command line is not passed into the recursion (which was the goal of adding the orig_flags variable in 98dbe63db). Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-29use @@PERL@@ in built scriptsLibravatar Jeff King1-1/+1
Several of the built shell commands invoke a bare "perl" to perform some one-liners. This will use the first perl in the PATH rather than the one specified by the user's SHELL_PATH. We are not asking these perl invocations to do anything exotic, so typically any old system perl will do; however, in some cases the system perl may have unexpected behavior (e.g., by handling line endings differently). We should err on the side of using the perl the user pointed us to. The downside of this is that on systems with a sane perl setup, we no longer find the perl at runtime, but instead point to a static perl (like /usr/bin/perl). That means we will not handle somebody moving perl without rebuilding git, whereas before we tracked it just fine. This is probably not a big deal, though, as the built perl scripts already suffered from this. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-27submodule foreach: skip eval for more than one argumentLibravatar Anders Kaseorg1-1/+6
'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-09-24Merge branch 'bc/submodule-status-ignored'Libravatar Jonathan Nieder1-4/+11
* bc/submodule-status-ignored: Improve documentation concerning the status.submodulesummary setting submodule: don't print status output with ignore=all submodule: fix confusing variable name
2013-09-06submodule summary: ignore --for-status optionLibravatar Matthieu Moy1-12/+1
The --for-status option was an undocumented option used only by wt-status.c, which inserted a header and commented out the output. We can achieve the same result within wt-status.c, without polluting the submodule command-line options. This will make it easier to disable the comments from wt-status.c later. The --for-status is kept so that another topic in flight (bc/submodule-status-ignored) can continue relying on it, although it is currently a no-op. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-04submodule: don't print status output with ignore=allLibravatar Brian M. Carlson1-0/+7
git status prints information for submodules, but it should ignore the status of those which have submodule.<name>.ignore set to all. Fix it so that it does properly ignore those which have that setting either in .git/config or in .gitmodules. Not ignored are submodules that are added, deleted, or moved (which is essentially a combination of the first two) because it is not easily possible to determine the old path once a move has occurred, nor is it easily possible to detect which adds and deletions are moves and which are not. This also preserves the previous behavior of always listing modules which are to be deleted. Tests are included which verify that this change has no effect on git submodule summary without the --for-status option. Signed-off-by: Brian M. Carlson <sandals@crustytoothpaste.net> Acked-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-03submodule: fix confusing variable nameLibravatar Brian M. Carlson1-4/+4
cmd_summary reads the output of git diff, but reads in the submodule path into a variable called name. Since this variable does not contain the name of the submodule, but the path, rename it to be clearer what data it actually holds. Signed-off-by: Brian M. Carlson <sandals@crustytoothpaste.net> Acked-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-15Merge branch 'fg/submodule-clone-depth'Libravatar Junio C Hamano1-3/+21
Allow shallow-cloning of submodules with "git submodule update". * fg/submodule-clone-depth: Add --depth to submodule update/add
2013-07-03Add --depth to submodule update/addLibravatar Fredrik Gustafsson1-3/+21
Add the --depth option to the add and update commands of "git submodule", which is then passed on to the clone command. This is useful when the submodule(s) are huge and you're not really interested in anything but the latest commit. Tests are added and some indention adjustments were made to conform to the rest of the testfile on "submodule update can handle symbolic links in pwd". Signed-off-by: Fredrik Gustafsson <iveqy@iveqy.com> Acked-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-03submodule update: allow custom command to update submodule working treeLibravatar Chris Packham1-0/+6
Users can set submodule.$name.update to '!command' which will cause 'command' to be run instead of checkout/merge/rebase. This allows the user finer-grained control over how the update is done. The primary motivation for this was interoperability with stgit; however being able to intercept the submodule update process may prove useful for integrating with or extending other tools. Signed-off-by: Chris Packham <judge.packham@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-30Merge branch 'jk/submodule-subdirectory-ok'Libravatar Junio C Hamano1-35/+100
Allow various subcommands of "git submodule" to be run not from the top of the working tree of the superproject. * jk/submodule-subdirectory-ok: submodule: drop the top-level requirement rev-parse: add --prefix option submodule: show full path in error message t7403: add missing && chaining t7403: modernize style t7401: make indentation consistent
2013-06-26Merge branch 'fg/submodule-non-ascii-path'Libravatar Junio C Hamano1-1/+2
Many "git submodule" operations do not work on a submodule at a path whose name is not in ASCII. * fg/submodule-non-ascii-path: t7400: test of UTF-8 submodule names pass under Mac OS handle multibyte characters in name
2013-06-17submodule: drop the top-level requirementLibravatar John Keeping1-35/+100
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>
2013-06-17submodule: show full path in error messageLibravatar John Keeping1-1/+1
When --recursive was added to "submodule foreach" in commit 15fc56a (git submodule foreach: Add --recursive to recurse into nested submodules, 2009-08-19), the error message when the script returns a non-zero status was not updated to contain $prefix to show the full path. Fix this. Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-17git-submodule.sh: remove duplicate call to set_rev_nameLibravatar Fredrik Gustafsson1-2/+2
set_rev_name is a possiblly expensive operation. If a submodule has changes in it, set_rev_name was called twice. Move call to set_rev_name so it's only called once, no matter which codepath is taken. Signed-off-by: Fredrik Gustafsson <iveqy@iveqy.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-14handle multibyte characters in nameLibravatar Fredrik Gustafsson1-1/+2
Many "git submodule" operations do not work on a submodule at a path whose name is not in ASCII. This is because "git ls-files" is used to find which paths are bound to submodules to the current working tree, and the output is C-quoted by default for non ASCII pathnames. Tell "git ls-files" to not C-quote its output, which is easier than unwrapping C-quote ourselves. Signed-off-by: Fredrik Gustafsson <iveqy@iveqy.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-05Merge branch 'jl/submodule-deinit'Libravatar Junio C Hamano1-2/+4
A finishing touch to the new topic in 1.8.3. * jl/submodule-deinit: submodule deinit: clarify work tree removal message
2013-04-03Merge branch 'rs/submodule-summary-limit'Libravatar Junio C Hamano1-6/+11
"submodule summary --summary-limit" option did not support "--option=value" form. * rs/submodule-summary-limit: submodule summary: support --summary-limit=<n>
2013-04-01submodule deinit: clarify work tree removal messageLibravatar Jens Lehmann1-2/+4
The output of "git submodule deinit sub" of a populated submodule prints rm 'sub' as the first line unless used with the -f option. The "rm 'sub'" line is exactly the same output the user gets when using "git rm sub" (because that command is used with the --dry-run option under the hood to determine if the submodule is clean), which can easily lead to the false impression that the submodule would be permanently removed. Also users might be confused that the "rm 'submodule'" line won't show up when the -f option is used, as the test is skipped in this case. Silence the "rm 'submodule'" output by using the --quiet option for "git rm" and always print Cleared directory 'submodule' instead as the first output line. This line is printed as long as the directory exists, no matter if empty or not. Also extend the tests in t7400 to make sure the "Cleared directory" line is printed correctly. Reported-by: Phil Hord <phil.hord@gmail.com> Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-01submodule summary: support --summary-limit=<n>Libravatar René Scharfe1-6/+11
In addition to "--summary-limit <n>" support the form "--summary-limit=<n>", for consistency with other parameters and commands. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-26Merge branch 'we/submodule-update-prefix-output' into maintLibravatar Junio C Hamano1-13/+18
"git submodule update", when recursed into sub-submodules, did not acccumulate the prefix paths. * we/submodule-update-prefix-output: submodule update: when using recursion, show full path
2013-03-25Merge branch 'jl/submodule-deinit'Libravatar Junio C Hamano1-1/+76
There was no Porcelain way to say "I no longer am interested in this submodule", once you express your interest in a submodule with "submodule init". "submodule deinit" is the way to do so. * jl/submodule-deinit: submodule: add 'deinit' command
2013-03-21Merge branch 'we/submodule-update-prefix-output'Libravatar Junio C Hamano1-13/+18
"git submodule update", when recursed into sub-submodules, did not acccumulate the prefix paths. * we/submodule-update-prefix-output: submodule update: when using recursion, show full path
2013-03-04submodule: add 'deinit' commandLibravatar Jens Lehmann1-1/+76
With "git submodule init" the user is able to tell git he cares about one or more submodules and wants to have it populated on the next call to "git submodule update". But currently there is no easy way he could tell git he does not care about a submodule anymore and wants to get rid of his local work tree (except he knows a lot about submodule internals and removes the "submodule.$name.url" setting from .git/config together with the work tree himself). Help those users by providing a 'deinit' command. This removes the whole submodule.<name> section from .git/config (either for the given submodule(s) or for all those which have been initialized if '.' is used) together with their work tree. Fail if the current work tree contains modifications (unless forced), but don't complain when either the work tree is already removed or no settings are found in .git/config. Add tests and link the man pages of "git submodule deinit" and "git rm" to assist the user in deciding whether removing or unregistering the submodule is the right thing to do for him. Also add the deinit subcommand to the completion list. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-03submodule update: when using recursion, show full pathLibravatar William Entriken1-13/+18
Previously when using update with recursion, only the path for the inner-most module was printed. Now the path is printed relative to the directory the command was started from. This now matches the behavior of submodule foreach. Signed-off-by: William Entriken <github.com@phor.net> Acked-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-16Allow custom "comment char"Libravatar Junio C Hamano1-4/+4
Some users do want to write a line that begin with a pound sign, #, in their commit log message. Many tracking system recognise a token of #<bugid> form, for example. The support we offer these use cases is not very friendly to the end users. They have a choice between - Don't do it. Avoid such a line by rewrapping or indenting; and - Use --cleanup=whitespace but remove all the hint lines we add. Give them a way to set a custom comment char, e.g. $ git -c core.commentchar="%" commit so that they do not have to do either of the two workarounds. [jc: although I started the topic, all the tests and documentation updates, many of the call sites of the new strbuf_add_commented_*() functions, and the change to git-submodule.sh scripted Porcelain are from Ralf.] Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-12-19submodule add: If --branch is given, record it in .gitmodulesLibravatar W. Trevor King1-0/+4
This allows you to easily record a submodule.<name>.branch option in .gitmodules when you add a new submodule. With this patch, $ git submodule add -b <branch> <repository> [<path>] $ git config -f .gitmodules submodule.<path>.branch <branch> reduces to $ git submodule add -b <branch> <repository> [<path>] This means that future calls to $ git submodule update --remote ... will get updates from the same branch that you used to initialize the submodule, which is usually what you want. Signed-off-by: W. Trevor King <wking@tremily.us> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-12-19submodule update: add --remote for submodule's upstream changesLibravatar W. Trevor King1-1/+20
The current `update` command incorporates the superproject's gitlinked SHA-1 ($sha1) into the submodule HEAD ($subsha1). Depending on the options you use, it may checkout $sha1, rebase the $subsha1 onto $sha1, or merge $sha1 into $subsha1. This helps you keep up with changes in the upstream superproject. However, it's also useful to stay up to date with changes in the upstream subproject. Previous workflows for incorporating such changes include the ungainly: $ git submodule foreach 'git checkout $(git config --file $toplevel/.gitmodules submodule.$name.branch) && git pull' With this patch, all of the useful functionality for incorporating superproject changes can be reused to incorporate upstream subproject updates. When you specify --remote, the target $sha1 is replaced with a $sha1 of the submodule's origin/master tracking branch. If you want to merge a different tracking branch, you can configure the `submodule.<name>.branch` option in `.gitmodules`. You can override the `.gitmodules` configuration setting for a particular superproject by configuring the option in that superproject's default configuration (using the usual configuration hierarchy, e.g. `.git/config`, `~/.gitconfig`, etc.). Previous use of submodule.<name>.branch ======================================= Because we're adding a new configuration option, it's a good idea to check if anyone else is already using the option. The foreach-pull example above was described by Ævar in commit f030c96d8643fa0a1a9b2bd9c2f36a77721fb61f Author: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Date: Fri May 21 16:10:10 2010 +0000 git-submodule foreach: Add $toplevel variable Gerrit uses the same interpretation for the setting, but because Gerrit has direct access to the subproject repositories, it updates the superproject repositories automatically when a subproject changes. Gerrit also accepts the special value '.', which it expands into the superproject's branch name. Although the --remote functionality is using `submodule.<name>.branch` slightly differently, the effect is the same. The foreach-pull example uses the option to record the name of the local branch to checkout before pulls. The tracking branch to be pulled is recorded in `.git/modules/<name>/config`, which was initialized by the module clone during `submodule add` or `submodule init`. Because the branch name stored in `submodule.<name>.branch` was likely the same as the branch name used during the initial `submodule add`, the same branch will be pulled in each workflow. Implementation details ====================== In order to ensure a current tracking branch state, `update --remote` fetches the submodule's remote repository before calculating the SHA-1. However, I didn't change the logic guarding the existing fetch: if test -z "$nofetch" then # Run fetch only if $sha1 isn't present or it # is not reachable from a ref. (clear_local_git_env; cd "$path" && ( (rev=$(git rev-list -n 1 $sha1 --not --all 2>/dev/null) && test -z "$rev") || git-fetch)) || die "$(eval_gettext "Unable to fetch in submodule path '\$path'")" fi There will not be a double-fetch, because the new $sha1 determined after the `--remote` triggered fetch should always exist in the repository. If it doesn't, it's because some racy process removed it from the submodule's repository and we *should* be re-fetching. Signed-off-by: W. Trevor King <wking@tremily.us> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-12-11submodule: add get_submodule_config helper funtionLibravatar W. Trevor King1-0/+26
Several submodule configuration variables (e.g. fetchRecurseSubmodules) are read from .gitmodules with local overrides from the usual git config files. This shell function mimics that logic to help initialize configuration variables in git-submodule.sh. Signed-off-by: W. Trevor King <wking@tremily.us> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-11-21Merge branch 'wtk/submodule-doc-fixup'Libravatar Junio C Hamano1-1/+1
* wtk/submodule-doc-fixup: git-submodule: wrap branch option with "<>" in usage strings.
2012-11-15Merge branch 'ph/submodule-sync-recursive'Libravatar Junio C Hamano1-2/+12
Adds "--recursive" option to submodule sync. * ph/submodule-sync-recursive: Add tests for submodule sync --recursive Teach --recursive to submodule sync
2012-11-09Merge branch 'ph/maint-submodule-status-fix'Libravatar Jeff King1-3/+1
Cleans up some leftover bits from an earlier submodule change. * ph/maint-submodule-status-fix: submodule status: remove unused orig_* variables t7407: Fix recursive submodule test
2012-11-04Merge branch 'sz/maint-submodule-reference-arg'Libravatar Jeff King1-1/+0
* sz/maint-submodule-reference-arg: submodule add: fix handling of --reference=<repo> option
2012-10-29Merge branch 'jl/submodule-add-by-name'Libravatar Jeff King1-11/+36
If you remove a submodule, in order to keep the repository so that "git checkout" to an older commit in the superproject history can resurrect the submodule, the real repository will stay in $GIT_DIR of the superproject. A later "git submodule add $path" to add a different submodule at the same path will fail. Diagnose this case a bit better, and if the user really wants to add an unrelated submodule at the same path, give the "--name" option to give it a place in $GIT_DIR of the superproject that does not conflict with the original submodule. * jl/submodule-add-by-name: submodule add: Fail when .git/modules/<name> already exists unless forced Teach "git submodule add" the --name option
2012-10-29Teach --recursive to submodule syncLibravatar Phil Hord1-2/+12
The submodule sync command was somehow left out when --recursive was added to the other submodule commands. Teach sync to handle the --recursive switch by recursing when we're in a submodule we are sync'ing. Change the report during sync to show submodule-path instead of submodule-name to be consistent with the other submodule commands and to help recursed paths make sense. Signed-off-by: Phil Hord <hordp@cisco.com> Acked-By: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Jeff King <peff@peff.net>
2012-10-29submodule status: remove unused orig_* variablesLibravatar Jens Lehmann1-3/+1
When renaming orig_args to orig_flags in 98dbe63d (submodule: only preserve flags across recursive status/update invocations) the call site of the recursive cmd_status was forgotten. At that place orig_args is still passed into the recursion, which is always empty since then. This did not break anything because the orig_flags logic is not needed at all when a function from the submodule script is called with eval, as that inherits all the variables set by the option parsing done in the first level of the recursion. Now that we know that orig_flags and orig_args aren't needed at all, let's just remove them from cmd_status(). Thanks-to: Phil Hord <hordp@cisco.com> Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Jeff King <peff@peff.net>
2012-10-26submodule add: fix handling of --reference=<repo> optionLibravatar Stefan Zager1-1/+0
Doing a shift here is wrong because there is no extra argument to consume when "--reference=<repo>" is used (note the '=' instead of a space). Signed-off-by: Stefan Zager <szager@google.com> Signed-off-by: Jeff King <peff@peff.net>
2012-10-25git-submodule: wrap branch option with "<>" in usage strings.Libravatar W. Trevor King1-1/+1
Use "-b <branch>" instead of "-b branch". This brings the usage strings in line with other options, e.g. "--reference <repository>". Signed-off-by: W. Trevor King <wking@tremily.us> Signed-off-by: Jeff King <peff@peff.net>
2012-10-02Merge branch 'rr/maint-submodule-unknown-cmd' into maintLibravatar Junio C Hamano1-1/+9
"git submodule frotz" was not diagnosed as "frotz" being an unknown subcommand to "git submodule"; the user instead got a complaint that "git submodule status" was run with an unknown path "frotz". * rr/maint-submodule-unknown-cmd: submodule: if $command was not matched, don't parse other args
2012-09-30submodule add: Fail when .git/modules/<name> already exists unless forcedLibravatar Jens Lehmann1-1/+14
When adding a new submodule it can happen that .git/modules/<name> already contains a submodule repo, e.g. when a submodule is removed from the work tree and another submodule is added at the same path. But then the work tree of the submodule will be populated using the existing repository and not the one the user provided, which results in an incorrect work tree. On the other hand the user might reactivate a submodule removed earlier, then reusing that .git directory is the Right Thing to do. As git can't decide what is the case, error out and tell the user she should use either use a different name for the submodule with the "--name" option or can reuse the .git directory for the newly added submodule by providing the --force option (which only makes sense when the upstream matches, so the error message lists all remotes of .git/modules/<name>). In one test in t7406 the --force option had to be added to "git submodule add", as that test re-adds a formerly removed submodule. Reported-by: Jonathan Johnson <me@jondavidjohn.com> Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-29Merge branch 'rr/maint-submodule-unknown-cmd'Libravatar Junio C Hamano1-1/+9
* rr/maint-submodule-unknown-cmd: submodule: if $command was not matched, don't parse other args
2012-09-29Teach "git submodule add" the --name optionLibravatar Jens Lehmann1-10/+22
"git submodule add" initializes the name of a submodule to its path. This was ok as long as the .git directory lived inside the submodule's work tree, but since 1.7.8 it is stored in the .git/modules/<name> directory of the superproject, making the submodule name survive the removal of the submodule's work tree. This leads to problems when the user tries to add a different submodule at the same path - and thus the same name - later, as that will happily try to restore the submodule from the old repository instead of the one the user specified and will lead to a checkout of the wrong repository. Add the new "--name" option to let the user provide a name for the submodule. This enables the user to solve this conflict without having to remove .git/modules/<name> by hand (which is no viable solution as it makes it impossible to checkout a commit that records the old submodule and populate it, as that will still check out the new submodule for the same reason). To achieve that the submodule's name is added to the parameter list of the module_clone() helper function. This makes it possible to remove the call of module_name() there because both callers of module_clone() already know the name and can provide it as argument number two. Reported-by: Jonathan Johnson <me@jondavidjohn.com> Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-25submodule: if $command was not matched, don't parse other argsLibravatar Ramkumar Ramachandra1-1/+9
"git submodule" command DWIMs the command line and assumes a unspecified action word for 'status' action. This is a UI mistake that leads to a confusing behaviour. A mistyped command name is instead treated as a request for 'status' of the submodule with that name, e.g. $ git submodule show error: pathspec 'show' did not match any file(s) known to git. Did you forget to 'git add'? Stop DWIMming an unknown or mistyped subcommand name as pathspec given to unspelled "status" subcommand. "git submodule" without any argument is still interpreted as "git submodule status", but its value is questionable. Adjust t7400 to match, and stop advertising the default subcommand being 'status' which does not help much in practice, other than promoting laziness and confusion. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>