summaryrefslogtreecommitdiff
path: root/git-submodule.sh
AgeCommit message (Collapse)AuthorFilesLines
2015-09-01Merge branch 'ah/submodule-typofix-in-error'Libravatar Junio C Hamano1-1/+1
Error string fix. * ah/submodule-typofix-in-error: git-submodule: remove extraneous space from error message
2015-08-28git-submodule: remove extraneous space from error messageLibravatar Alex Henrie1-1/+1
Signed-off-by: Alex Henrie <alexhenrie24@gmail.com> Acked-by: Chris Packham <judge.packham@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-02-22Merge branch 'ps/submodule-sanitize-path-upon-add'Libravatar Junio C Hamano1-1/+1
"git submodule add" failed to squash "path/to/././submodule" to "path/to/submodule". * ps/submodule-sanitize-path-upon-add: git-submodule.sh: fix '/././' path normalization
2015-02-02git-submodule.sh: fix '/././' path normalizationLibravatar Patrick Steinhardt1-1/+1
When we add a new submodule the path of the submodule is being normalized. We fail to normalize multiple adjacent '/./', though. Thus 'path/to/././submodule' will become 'path/to/./submodule' where it should be 'path/to/submodule' instead. Signed-off-by: Patrick Steinhardt <ps@pks.im> Acked-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-06-19git-submodule.sh: avoid "echo" path-like valuesLibravatar Junio C Hamano1-8/+8
SysV-derived implementation of "echo" interprets some backslash sequences as special instruction, e.g. "echo 'ab\c'" shows an incomplete line with 'a' and 'b' on it. Avoid using it when showing a path-like values in the script. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-06-19git-submodule.sh: avoid "test <cond> -a/-o <cond>"Libravatar Elia Pinto1-12/+20
The construct is error-prone; "test" being built-in in most modern shells, the reason to avoid "test <cond> && test <cond>" spawning one extra process by using a single "test <cond> -a <cond>" no longer exists. Signed-off-by: Elia Pinto <gitter.spiros@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-06-06Merge branch 'sk/submodules-absolute-path-on-windows'Libravatar Junio C Hamano1-3/+0
* sk/submodules-absolute-path-on-windows: Revert "submodules: fix ambiguous absolute paths under Windows"
2014-05-08Revert "submodules: fix ambiguous absolute paths under Windows"Libravatar Stepan Kasal1-3/+0
This reverts commit 4dce7d9b408b2935b85721b54a2010eda7ec1be9, which was originally done to help Windows but was almost immediately reverted in msysGit, and the codebase kept this unnecessary divergence for almost two years. Signed-off-by: Stepan Kasal <kasal@ucw.cz> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-04-02Revert "submodule: explicit local branch creation in module_clone"Libravatar Junio C Hamano1-41/+17
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.
2014-03-14Merge branch 'jl/doc-submodule-update-checkout'Libravatar Junio C Hamano1-1/+1
Add missing documentation for "submodule update --checkout". * jl/doc-submodule-update-checkout: submodule update: consistently document the '--checkout' option
2014-02-28submodule update: consistently document the '--checkout' optionLibravatar Jens Lehmann1-1/+1
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>
2014-02-27Merge branch 'wk/submodule-on-branch'Libravatar Junio C Hamano1-32/+57
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
2014-02-24submodule: explicit local branch creation in module_cloneLibravatar W. Trevor King1-17/+41
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>
2014-02-24submodule: document module_clone arguments in commentsLibravatar W. Trevor King1-0/+6
Signed-off-by: W. Trevor King <wking@tremily.us> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-02-24submodule: make 'checkout' update_module mode more explicitLibravatar W. Trevor King1-16/+11
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>
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>