summaryrefslogtreecommitdiff
path: root/t/t7406-submodule-update.sh
AgeCommit message (Collapse)AuthorFilesLines
2015-03-20t: fix trivial &&-chain breakageLibravatar Jeff King1-1/+1
These are tests which are missing a link in their &&-chain, but during a setup phase. We may fail to notice failure in commands that build the test environment, but these are typically not expected to fail at all (but it's still good to double-check that our test environment is what we expect). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-04-02Revert "submodule: explicit local branch creation in module_clone"Libravatar Junio C Hamano1-38/+1
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-02-27Merge branch 'wk/submodule-on-branch'Libravatar Junio C Hamano1-1/+37
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-1/+38
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>
2013-12-05Merge branch 'jl/submodule-update-retire-orig-flags'Libravatar Junio C Hamano1-0/+11
Code clean-up. * jl/submodule-update-retire-orig-flags: submodule update: remove unnecessary orig_flags variable
2013-12-02submodule: do not copy unknown update mode from .gitmodulesLibravatar Junio C Hamano1-0/+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-0/+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>
2013-09-17t7406-submodule-update: add missing &&Libravatar Tay Ray Chuan1-1/+1
322bb6e (2011 Aug 11) introduced a new subshell at the end of a test case but omitted a '&&' to join the two; fix this. Signed-off-by: Tay Ray Chuan <rctay89@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-15Merge branch 'fg/submodule-clone-depth'Libravatar Junio C Hamano1-7/+17
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-7/+17
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/+29
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-17submodule: drop the top-level requirementLibravatar John Keeping1-0/+15
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-04-18Merge branch 'jc/push-2.0-default-to-simple' (early part)Libravatar Junio C Hamano1-2/+2
Adjust our tests for upcoming migration of the default value for the "push.default" configuration variable to "simple" from "mixed". * 'jc/push-2.0-default-to-simple' (early part): t5570: do not assume the "matching" push is the default t5551: do not assume the "matching" push is the default t5550: do not assume the "matching" push is the default t9401: do not assume the "matching" push is the default t9400: do not assume the "matching" push is the default t7406: do not assume the "matching" push is the default t5531: do not assume the "matching" push is the default t5519: do not assume the "matching" push is the default t5517: do not assume the "matching" push is the default t5516: do not assume the "matching" push is the default t5505: do not assume the "matching" push is the default t5404: do not assume the "matching" push is the default
2013-04-01Merge branch 'nd/branch-show-rebase-bisect-state'Libravatar Junio C Hamano1-2/+4
Add a bit more information to "git status" during a rebase/bisect session. * nd/branch-show-rebase-bisect-state: status, branch: fix the misleading "bisecting" message branch: show more information when HEAD is detached status: show more info than "currently not on any branch" wt-status: move wt_status_get_state() out to wt_status_print() wt-status: split wt_status_state parsing function out wt-status: move strbuf into read_and_strip_branch()
2013-03-21Merge branch 'we/submodule-update-prefix-output'Libravatar Junio C Hamano1-1/+2
"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-16status: show more info than "currently not on any branch"Libravatar Nguyễn Thái Ngọc Duy1-2/+4
When a remote ref or a tag is checked out, HEAD is automatically detached. There is no user-friendly way to find out what ref is checked out in this case. This patch digs in reflog for this information and shows "HEAD detached from origin/master" or "HEAD detached at v1.8.0" instead of "currently not on any branch". When it cannot figure out the original ref, it shows an abbreviated SHA-1. "Currently not on any branch" would never display (unless reflog is pruned to near empty that the last checkout entry is lost). Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-03submodule update: when using recursion, show full pathLibravatar William Entriken1-1/+2
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-04t7406: do not assume the "matching" push is the defaultLibravatar Junio C Hamano1-2/+2
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-12-19submodule update: add --remote for submodule's upstream changesLibravatar W. Trevor King1-0/+31
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-09-30submodule add: Fail when .git/modules/<name> already exists unless forcedLibravatar Jens Lehmann1-1/+1
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-03Merge branch 'sz/submodule-force-update'Libravatar Junio C Hamano1-0/+12
"git submodule update --force" used to leave the working tree of the submodule intact when there were local changes. It is more intiutive to make "--force" a sign to run "checkout -f" to overwrite them. * sz/submodule-force-update: Make 'git submodule update --force' always check out submodules.
2012-08-27Merge branch 'jc/maint-t7406-rev-parse-max-count-huh'Libravatar Junio C Hamano1-8/+8
Test clean-up, with no behaviour change. * jc/maint-t7406-rev-parse-max-count-huh: t7406: fix misleading "rev-parse --max-count=1 HEAD"
2012-08-24Make 'git submodule update --force' always check out submodules.Libravatar Stefan Zager1-0/+12
Currently, it will only do a checkout if the sha1 registered in the containing repository doesn't match the HEAD of the submodule, regardless of whether the submodule is dirty. As discussed on the mailing list, the '--force' flag is a strong indicator that the state of the submodule is suspect, and should be reset to HEAD. Signed-off-by: Stefan Zager <szager@google.com> Acked-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-30t7406: fix misleading "rev-parse --max-count=1 HEAD"Libravatar Junio C Hamano1-8/+8
The test happened to use "rev-parse --max-count=1 HEAD" consistently to prepare the expected output and the actual output, so the comparison between them gave us a correct success/failure because both output had irrelevant "--max-count=1" in it. But that is not an excuse to keep it broken. Replace it a more meaningful construct "rev-parse --verify HEAD". Noticed by Daniel Graña while working on his submodule tests. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-12submodules: don't stumble over symbolic links when cloning recursivelyLibravatar Jens Lehmann1-0/+13
Since 69c3051 (submodules: refactor computation of relative gitdir path) cloning a submodule recursively fails for nested submodules when a symbolic link is part of the path to the work tree of the superproject. This happens when module_clone() tries to find the relative paths between the work tree and the git dir. When a symbolic link in current $PWD points to a directory that is at a different level, then determining the number of "../" needed to traverse to the superproject's work tree leads to a wrong result. As there is no portable way to say "pwd -P", use cd_to_toplevel to remove the link from $PWD, which fixes this problem. A test for this issue has been added to t7406. Reported-by: Bob Halley <halley@play-bow.org> Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-03-04submodules: refactor computation of relative gitdir pathLibravatar Jens Lehmann1-0/+17
In module_clone() the rel_gitdir variable was computed differently when "git rev-parse --git-dir" returned a relative path than when it returned an absolute path. This is not optimal, as different code paths are used depending on the return value of that command. Fix that by reusing the differing path components computed for setting the core.worktree config setting, which leaves a single code path for setting both instead of having three and makes the code much shorter. This also fixes the bug that in the computation of how many directories have to be traversed up to hit the root directory of the submodule the name of the submodule was used where the path should have been used. This lead to problems after renaming submodules into another directory level. Even though the "(cd $somewhere && pwd)" approach breaks the flexibility of symlinks, that is no issue here as we have to have one relative path pointing from the work tree to the gitdir and another pointing back, which will never work anyway when a symlink along one of those paths is changed because the directory it points to was moved. Also add a test moving a submodule into a deeper directory to catch any future breakage here and to document what has to be done when a submodule needs to be moved until git mv learns to do that. Simply moving it to the new location doesn't work, as the core.worktree and possibly the gitfile setting too will be wrong. So it has to be removed from filesystem and index, then the new location has to be added into the index and the .gitmodules file has to be updated. After that a git submodule update will check out the submodule at the new location. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-01-24submodule add: fix breakage when re-adding a deep submoduleLibravatar Jens Lehmann1-0/+8
Since recently a submodule with name <name> has its git directory in the .git/modules/<name> directory of the superproject while the work tree contains a gitfile pointing there. When the same submodule is added on a branch where it wasn't present so far (it is not found in the .gitmodules file), the name is not initialized from the path as it should. This leads to a wrong path entered in the gitfile when the .git/modules/<name> directory is found, as this happily uses the - now empty - name. It then always points only a single directory up, even if we have a path deeper in the directory hierarchy. Fix that by initializing the name of the submodule early in module_clone() if module_name() returned an empty name and add a test to catch that bug. Reported-by: Jehan Bing <jehan@orb.com> Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-10Merge branch 'hv/submodule-update-none'Libravatar Junio C Hamano1-0/+62
* hv/submodule-update-none: add update 'none' flag to disable update of submodule by default submodule: move update configuration variable further up
2011-08-22Move git-dir for submodulesLibravatar Fredrik Gustafsson1-0/+107
Move git-dir for submodules into $GIT_DIR/modules/[name_of_submodule] of the superproject. This is a step towards being able to delete submodule directories without loosing the information from their .git directory as that is now stored outside the submodules work tree. This is done relying on the already existent .git-file functionality. When adding or updating a submodule whose git directory is found under $GIT_DIR/modules/[name_of_submodule], don't clone it again but simply point the .git-file to it and remove the now stale index file from it. The index will be recreated by the following checkout. This patch will not affect already cloned submodules at all. Tests that rely on .git being a directory have been fixed. Signed-off-by: Fredrik Gustafsson <iveqy@iveqy.com> Mentored-by: Jens Lehmann <Jens.Lehmann@web.de> Mentored-by: Heiko Voigt <hvoigt@hvoigt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-11add update 'none' flag to disable update of submodule by defaultLibravatar Heiko Voigt1-0/+62
This is useful to mark a submodule as unneeded by default. When this option is set and the user wants to work with such a submodule he needs to configure 'submodule.<name>.update=checkout' or pass the --checkout option. Then the submodule can be handled like a normal submodule. Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-07-13Merge branch 'fg/submodule-keep-updating'Libravatar Junio C Hamano1-0/+144
* fg/submodule-keep-updating: git-submodule.sh: clarify the "should we die now" logic submodule update: continue when a checkout fails git-sh-setup: add die_with_status Conflicts: git-submodule.sh
2011-06-13submodule update: continue when a checkout failsLibravatar Fredrik Gustafsson1-0/+144
"git submodule update" stops at the first error and gives control back to the user. Only after the user fixes the problematic submodule and runs "git submodule update" again, the second error is found. And the user needs to repeat until all the problems are found and fixed one by one. This is tedious. Instead, the command can remember which submodules it had trouble with, continue updating the ones it can, and report which ones had errors at the end. The user can run "git submodule update", find all the ones that need minor fixing (e.g. working tree was dirty) to fix them in a single pass. Then another "git submodule update" can be run to update all. Note that the problematic submodules are skipped only when they are to be integrated with a safer value of submodule.<name>.update option, namely "checkout". Fixing a failure in a submodule that uses "rebase" or "merge" may need an involved conflict resolution by the user, and leaving too many submodules in states that need resolution would not reduce the mental burden on the user. Signed-off-by: Fredrik Gustafsson <iveqy@iveqy.com> Mentored-by: Jens Lehmann <Jens.Lehmann@web.de> Mentored-by: Heiko Voigt <hvoigt@hvoigt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-21i18n: git-submodule $update_module say + die messagesLibravatar Ævar Arnfjörð Bjarmason1-1/+1
Gettextize $update_module say and die messages. These messages needed to be split up to make them translatable. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-02Merge branch 'nm/submodule-update-force'Libravatar Junio C Hamano1-0/+23
* nm/submodule-update-force: submodule: Add --force option for git submodule update Conflicts: t/t7406-submodule-update.sh
2011-04-04Merge branch 'jl/submodule-fetch-on-demand'Libravatar Junio C Hamano1-0/+20
* jl/submodule-fetch-on-demand: fetch/pull: Describe --recurse-submodule restrictions in the BUGS section submodule update: Don't fetch when the submodule commit is already present fetch/pull: Don't recurse into a submodule when commits are already present Submodules: Add 'on-demand' value for the 'fetchRecurseSubmodule' option config: teach the fetch.recurseSubmodules option the 'on-demand' value fetch/pull: Add the 'on-demand' value to the --recurse-submodules option fetch/pull: recurse into submodules when necessary Conflicts: builtin/fetch.c submodule.c
2011-04-04submodule: Add --force option for git submodule updateLibravatar Nicolas Morey-Chaisemartin1-0/+23
By default git submodule update runs a simple checkout on submodules that are not up-to-date. If the submodules contains modified or untracked files, the command may exit sanely with an error: $ git submodule update error: Your local changes to the following files would be overwritten by checkout: file Please, commit your changes or stash them before you can switch branches. Aborting Unable to checkout '1b69c6e55606b48d3284a3a9efe4b58bfb7e8c9e' in submodule path 'test1' In order to reset a whole git submodule tree, a user has to run first 'git submodule foreach --recursive git checkout -f' and then run 'git submodule update'. This patch adds a --force option for the update command (only used for submodules without --rebase or --merge options). It passes the --force option to git checkout which will throw away the local changes. Signed-off-by: Nicolas Morey-Chaisemartin <nmorey@kalray.eu> Acked-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-09submodule update: Don't fetch when the submodule commit is already presentLibravatar Jens Lehmann1-0/+20
If the commit to be checked out on "git submodule update" has already been fetched in the submodule there is no need to run "git fetch" again. Since "git fetch" recently learned recursion (and the new on-demand mode to fetch commits recorded in the superproject is enabled by default) this will happen pretty often, thereby making the unconditional fetch during "git submodule update" unnecessary. If the commit is not present in the submodule (e.g. the user disabled the fetch on-demand mode) the fetch will be run as before. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-02-17t7406: "git submodule update {--merge|--rebase]" with new submodulesLibravatar Spencer E. Olson1-0/+52
Add two test cases in t7406 to ensure that the --merge/--rebase options are ignored for "git submodule update" with new modules. These test that a simple checkout is performed instead. Signed-off-by: Spencer E. Olson <olsonse@umich.edu> Acked-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-03t7406 & t7407: add missing && at end of linesLibravatar Jens Lehmann1-1/+1
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-03-06t7406: Fix submodule init config testsLibravatar Stephen Boyd1-8/+16
These tests have been broken since they were introduced in commits ca2cedb (git-submodule: add support for --rebase., 2009-04-24) and 42b4917 (git-submodule: add support for --merge., 2009-06-03). 'git submodule init' expects the submodules to exist in the index. In this case, the submodules don't exist and therefore looking for the submodules will always fail. To make matters worse, git submodule fails visibly to the user by saying: error: pathspec 'rebasing' did not match any file(s) known to git. Did you forget to 'git add'? but doesn't return an error code. This allows the test to fail silently. Fix it by adding the submodules first. Cc: Johan Herland <johan@herland.net> Cc: Peter Hutterer <peter.hutterer@who-t.net> Cc: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Stephen Boyd <bebarino@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-29t3409 t4107 t7406 t9150: use dashless commandsLibravatar Matthew Ogilvie1-2/+2
This is needed to allow test suite to run against a standard install bin directory instead of GIT_EXEC_PATH. Signed-off-by: Matthew Ogilvie <mmogilvi_git@miniinfo.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-06-03git-submodule: add support for --merge.Libravatar Johan Herland1-1/+59
'git submodule update --merge' merges the commit referenced by the superproject into your local branch, instead of checking it out on a detached HEAD. As evidenced by the addition of "git submodule update --rebase", it is useful to provide alternatives to the default 'checkout' behaviour of "git submodule update". One such alternative is, when updating a submodule to a new commit, to merge that commit into the current local branch in that submodule. This is useful in workflows where you want to update your submodule from its upstream, but you cannot use --rebase, because you have downstream people working on top of your submodule branch, and you don't want to disrupt their work. Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-06-03Rename submodule.<name>.rebase to submodule.<name>.updateLibravatar Johan Herland1-8/+8
The addition of "submodule.<name>.rebase" demonstrates the usefulness of alternatives to the default behaviour of "git submodule update". However, by naming the config variable "submodule.<name>.rebase", and making it a boolean choice, we are artificially constraining future git versions that may want to add _more_ alternatives than just "rebase". Therefore, while "submodule.<name>.rebase" is not yet in a stable git release, future-proof it, by changing it from submodule.<name>.rebase = true/false to submodule.<name>.update = rebase/checkout where "checkout" specifies the default behaviour of "git submodule update" (checking out the new commit to a detached HEAD), and "rebase" specifies the --rebase behaviour (where the current local branch in the submodule is rebase onto the new commit). Thus .update == checkout is equivalent to .rebase == false, and .update == rebase is equivalent to .rebase == true. Finally, leaving .update unset is equivalent to leaving .rebase unset. In future git versions, other alternatives to "git submodule update" behaviour can be included by adding them to the list of allowable values for the submodule.<name>.update variable. Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-04-24git-submodule: add support for --rebase.Libravatar Peter Hutterer1-0/+140
'git submodule update --rebase' rebases your local branch on top of what would have been checked out to a detached HEAD otherwise. In some cases, detaching the HEAD when updating a submodule complicates the workflow to commit to this submodule (checkout master, rebase, then commit). For submodules that require frequent updates but infrequent (if any) commits, a rebase can be executed directly by the git-submodule command, ensuring that the submodules stay on their respective branches. git-config key: submodule.$name.rebase (bool) Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>