aboutsummaryrefslogtreecommitdiff
path: root/git-submodule.sh
Commit message (Collapse)AuthorAge
* Revert "submodule: explicit local branch creation in module_clone"Junio C Hamano2014-04-02
| | | | | | This reverts commit 23d25e48f5ead73c9ce233986f90791abec9f1e8, as it is broken for users who haven't opted into the new feature of checking out submodule.*.branch with update mode set to checkout.
* Merge branch 'jl/doc-submodule-update-checkout'Junio C Hamano2014-03-14
|\ | | | | | | | | | | | | Add missing documentation for "submodule update --checkout". * jl/doc-submodule-update-checkout: submodule update: consistently document the '--checkout' option
| * submodule update: consistently document the '--checkout' optionJens Lehmann2014-02-28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 322bb6e12f (add update 'none' flag to disable update of submodule by default) added the '--checkout' option to "git submodule update" but forgot to explicitly document it in synopsis, usage string and man page (It is only mentioned implicitly in the man page). In 23d25e48 (submodule: explicit local branch creation in module_clone) the synopsis of the man page was updated, but the "OPTIONS" section of the man page and the usage string of the git-submodule script still do not mention the '--checkout' option. Fix that by documenting this option in usage string and the "OPTIONS" section of man page too. While at it group the update-mode options into a single set in the usage string. Reported-by: Matthijs Kooijman <matthijs@stdin.nl> Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'wk/submodule-on-branch'Junio C Hamano2014-02-27
|\ \ | |/ | | | | | | | | | | | | | | | | | | | | Make sure 'submodule update' modes that do not detach HEADs can be used more pleasantly by checking out a concrete branch when cloning them to prime the well. * wk/submodule-on-branch: Documentation: describe 'submodule update --remote' use case submodule: explicit local branch creation in module_clone submodule: document module_clone arguments in comments submodule: make 'checkout' update_module mode more explicit
| * submodule: explicit local branch creation in module_cloneW. Trevor King2014-02-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The previous code only checked out branches in cmd_add. This commit moves the branch-checkout logic into module_clone, where it can be shared by cmd_add and cmd_update. I also update the initial checkout command to use 'reset' to preserve branches setup during module_clone. With this change, folks cloning submodules for the first time via: $ git submodule update ... will get a local branch instead of a detached HEAD, unless they are using the default checkout-mode updates. This is a change from the previous situation where cmd_update always used checkout-mode logic (regardless of the requested update mode) for updates that triggered an initial clone, which always resulted in a detached HEAD. This commit does not change the logic for updates after the initial clone, which will continue to create detached HEADs for checkout-mode updates, and integrate remote work with the local HEAD (detached or not) in other modes. The motivation for the change is that developers doing local work inside the submodule are likely to select a non-checkout-mode for updates so their local work is integrated with upstream work. Developers who are not doing local submodule work stick with checkout-mode updates so any apparently local work is blown away during updates. For example, if upstream rolls back the remote branch or gitlinked commit to an earlier version, the checkout-mode developer wants their old submodule checkout to be rolled back as well, instead of getting a no-op merge/rebase with the rolled-back reference. By using the update mode to distinguish submodule developers from black-box submodule consumers, we can setup local branches for the developers who will want local branches, and stick with detached HEADs for the developers that don't care. Testing ======= In t7406, just-cloned checkouts now update to the gitlinked hash with 'reset', to preserve the local branch for situations where we're not on a detached HEAD. I also added explicit tests to t7406 for HEAD attachement after cloning updates, showing that it depends on their update mode: * Checkout-mode updates get detached HEADs * Everyone else gets a local branch, matching the configured submodule.<name>.branch and defaulting to master. The 'initial-setup' tag makes it easy to reset the superproject to a known state, as several earlier tests commit to submodules and commit the changed gitlinks to the superproject, but don't push the new submodule commits to the upstream subprojects. This makes it impossible to checkout the current super master, because it references submodule commits that don't exist in the upstream subprojects. For a specific example, see the tests that currently generate the 'two_new_submodule_commits' commits. Documentation ============= I updated the docs to describe the 'submodule update' modes in detail. The old documentation did not distinguish between cloning and non-cloning updates and lacked clarity on which operations would lead to detached HEADs, and which would not. The new documentation addresses these issues while updating the docs to reflect the changes introduced by this commit's explicit local branch creation in module_clone. I also add '--checkout' to the usage summary and group the update-mode options into a single set. Signed-off-by: W. Trevor King <wking@tremily.us> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * submodule: document module_clone arguments in commentsW. Trevor King2014-02-24
| | | | | | | | | | Signed-off-by: W. Trevor King <wking@tremily.us> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * submodule: make 'checkout' update_module mode more explicitW. Trevor King2014-02-24
| | | | | | | | | | | | | | | | | | This avoids the current awkwardness of having either '' or 'checkout' for checkout-mode updates, which makes testing for checkout-mode updates (or non-checkout-mode updates) easier. Signed-off-by: W. Trevor King <wking@tremily.us> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'fp/submodule-checkout-mode'Junio C Hamano2014-01-17
|\ \ | |/ | | | | | | | | | | | | | | "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
| * git-submodule.sh: 'checkout' is a valid update modeFrancesco Pretto2014-01-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | '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>
* | Merge branch 'jl/submodule-update-retire-orig-flags'Junio C Hamano2013-12-05
|\ \ | | | | | | | | | | | | | | | | | | Code clean-up. * jl/submodule-update-retire-orig-flags: submodule update: remove unnecessary orig_flags variable
| * | submodule update: remove unnecessary orig_flags variableJens Lehmann2013-11-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | Merge branch 'jk/replace-perl-in-built-scripts'Junio C Hamano2013-12-05
|\ \ \ | | | | | | | | | | | | | | | | * jk/replace-perl-in-built-scripts: use @@PERL@@ in built scripts
| * | | use @@PERL@@ in built scriptsJeff King2013-10-29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | | Merge branch 'ak/submodule-foreach-quoting'Junio C Hamano2013-12-05
|\ \ \ \ | |_|_|/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
| * | | submodule foreach: skip eval for more than one argumentAnders Kaseorg2013-09-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | '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>
* | | | Sync with 1.8.4.5Junio C Hamano2013-12-02
|\ \ \ \ | |_|_|/ |/| | |
| * | | submodule: do not copy unknown update mode from .gitmodulesJunio C Hamano2013-12-02
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | Merge branch 'bc/submodule-status-ignored'Jonathan Nieder2013-09-24
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | * 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
| * | | submodule: don't print status output with ignore=allBrian M. Carlson2013-09-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | | submodule: fix confusing variable nameBrian M. Carlson2013-09-03
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | submodule summary: ignore --for-status optionMatthieu Moy2013-09-06
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Merge branch 'fg/submodule-clone-depth'Junio C Hamano2013-07-15
|\ \ | | | | | | | | | | | | | | | | | | Allow shallow-cloning of submodules with "git submodule update". * fg/submodule-clone-depth: Add --depth to submodule update/add
| * | Add --depth to submodule update/addFredrik Gustafsson2013-07-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | submodule update: allow custom command to update submodule working treeChris Packham2013-07-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | Merge branch 'jk/submodule-subdirectory-ok'Junio C Hamano2013-06-30
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
| * | | submodule: drop the top-level requirementJohn Keeping2013-06-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | | submodule: show full path in error messageJohn Keeping2013-06-17
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | Merge branch 'fg/submodule-non-ascii-path'Junio C Hamano2013-06-26
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
| * | | handle multibyte characters in nameFredrik Gustafsson2013-06-14
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | git-submodule.sh: remove duplicate call to set_rev_nameFredrik Gustafsson2013-06-17
|/ / | | | | | | | | | | | | | | | | | | | | 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>
* | Merge branch 'jl/submodule-deinit'Junio C Hamano2013-04-05
|\ \ | | | | | | | | | | | | | | | | | | A finishing touch to the new topic in 1.8.3. * jl/submodule-deinit: submodule deinit: clarify work tree removal message
| * | submodule deinit: clarify work tree removal messageJens Lehmann2013-04-01
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | Merge branch 'rs/submodule-summary-limit'Junio C Hamano2013-04-03
|\ \ \ | | |/ | |/| | | | | | | | | | | | | | | | "submodule summary --summary-limit" option did not support "--option=value" form. * rs/submodule-summary-limit: submodule summary: support --summary-limit=<n>
| * | submodule summary: support --summary-limit=<n>René Scharfe2013-04-01
| | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | Merge branch 'we/submodule-update-prefix-output' into maintJunio C Hamano2013-03-26
| |\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | "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
* | \ \ Merge branch 'jl/submodule-deinit'Junio C Hamano2013-03-25
|\ \ \ \ | | |_|/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | 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
| * | | submodule: add 'deinit' commandJens Lehmann2013-03-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | | Merge branch 'we/submodule-update-prefix-output'Junio C Hamano2013-03-21
|\ \ \ \ | |_|/ / |/| | / | | |/ | |/| | | | | | | | | | "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
| * | submodule update: when using recursion, show full pathWilliam Entriken2013-03-03
| |/ | | | | | | | | | | | | | | | | | | | | 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>
* | Allow custom "comment char"Junio C Hamano2013-01-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | submodule add: If --branch is given, record it in .gitmodulesW. Trevor King2012-12-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | submodule update: add --remote for submodule's upstream changesW. Trevor King2012-12-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | submodule: add get_submodule_config helper funtionW. Trevor King2012-12-11
|/ | | | | | | | | | | 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>
* Merge branch 'wtk/submodule-doc-fixup'Junio C Hamano2012-11-21
|\ | | | | | | | | * wtk/submodule-doc-fixup: git-submodule: wrap branch option with "<>" in usage strings.
| * git-submodule: wrap branch option with "<>" in usage strings.W. Trevor King2012-10-25
| | | | | | | | | | | | | | | | 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>
* | Merge branch 'ph/submodule-sync-recursive'Junio C Hamano2012-11-15
|\ \ | | | | | | | | | | | | | | | | | | | | | Adds "--recursive" option to submodule sync. * ph/submodule-sync-recursive: Add tests for submodule sync --recursive Teach --recursive to submodule sync
| * | Teach --recursive to submodule syncPhil Hord2012-10-29
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Merge branch 'ph/maint-submodule-status-fix'Jeff King2012-11-09
|\ \ | | | | | | | | | | | | | | | | | | | | | 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
| * | submodule status: remove unused orig_* variablesJens Lehmann2012-10-29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | Merge branch 'sz/maint-submodule-reference-arg'Jeff King2012-11-04
|\ \ \ | | | | | | | | | | | | | | | | * sz/maint-submodule-reference-arg: submodule add: fix handling of --reference=<repo> option