summaryrefslogtreecommitdiff
path: root/t/t7403-submodule-sync.sh
AgeCommit message (Collapse)AuthorFilesLines
2012-10-29Add tests for submodule sync --recursiveLibravatar Phil Hord1-2/+53
Signed-off-by: Phil Hord <hordp@cisco.com> Acked-By: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Jeff King <peff@peff.net>
2012-06-06submodule: fix handling of superproject origin URLs like foo, ./foo and ↵Libravatar Jon Seymour1-3/+3
./foo/bar Currently git submodule init and git submodule sync fail with an error if the superproject origin URL is of the form foo but succeed if the superproject origin URL is of the form ./foo or ./foo/bar or foo/bar. This change makes handling of the foo case behave like the handling of the ./foo case and also ensures that superfluous leading and embedded ./'s are removed from the resulting derived URLs. Signed-off-by: Jon Seymour <jon.seymour@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-06-06submodule: fix sync handling of some relative superproject origin URLsLibravatar Jon Seymour1-4/+4
When the origin URL of the superproject is itself relative, git submodule sync configures the remote.origin.url configuration property of the submodule with a path that is relative to the work tree of the superproject rather than the work tree of the submodule. To fix this an 'up_path' that navigates from the work tree of the submodule to the work tree of the superproject needs to be prepended to the URL otherwise calculated. Correct handling of superproject origin URLs like foo, ./foo and ./foo/bar is left to a subsequent patch since an additional change is required to handle these cases. The documentation of resolve_relative_url() is expanded to give a more thorough description of the function's objective. Signed-off-by: Jon Seymour <jon.seymour@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-06-03submodule: document failure to handle relative superproject origin URLsLibravatar Jon Seymour1-1/+89
This test case documents several cases where handling of relative superproject origin URLs doesn't produce an expected result. submodule.{sub}.url in the superproject is incorrect in these cases: foo ./foo ./foo/bar The remote.origin.url of the submodule is incorrect in the above cases and also when the superproject origin URL is like: foo/bar ../foo ../foo/bar Signed-off-by: Jon Seymour <jon.seymour@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-16rev-parse: add option --resolve-git-dir <path>Libravatar Fredrik Gustafsson1-2/+3
Check if <path> is a valid git-dir or a valid git-file that points to a valid git-dir. We want tests to be independent from the fact that a git-dir may be a git-file. Thus we changed tests to use this feature. Signed-off-by: Fredrik Gustafsson <iveqy@iveqy.com> Mentored-by: Jens Lehmann <Jens.Lehmann@web.de> Mentored-by: Heiko Voigt <hvoigt@hvoigt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-07-19Merge branch 'jc/submodule-sync-no-auto-vivify'Libravatar Junio C Hamano1-2/+13
* jc/submodule-sync-no-auto-vivify: submodule add: always initialize .git/config entry submodule sync: do not auto-vivify uninteresting submodule Conflicts: git-submodule.sh
2011-06-26submodule sync: do not auto-vivify uninteresting submoduleLibravatar Junio C Hamano1-2/+13
Earlier 33f072f (submodule sync: Update "submodule.<name>.url" for empty directories, 2010-10-08) attempted to fix a bug where "git submodule sync" command does not update the URL if the current superproject does not have a checkout of the submodule. However, it did so by unconditionally registering submodule.$name.url to every submodule in the project, even the ones that the user has never showed interest in at all by running 'git submodule init' command. This caused subsequent 'git submodule update' to start cloning/updating submodules that are not interesting to the user at all. Update the code so that the URL is updated from the .gitmodules file only for submodules that already have submodule.$name.url entries, i.e. the ones the user has showed interested in having a checkout. Acked-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-09fetch/pull: recurse into submodules when necessaryLibravatar Jens Lehmann1-1/+1
To be able to access all commits of populated submodules referenced by the superproject it is sufficient to only then let "git fetch" recurse into a submodule when the new commits fetched in the superproject record new commits for it. Having these commits present is extremely useful when using the "--submodule" option to "git diff" (which is what "git gui" and "gitk" do since 1.6.6), as all submodule commits needed for creating a descriptive output can be accessed. Also merging submodule commits (added in 1.7.3) depends on the submodule commits in question being present to work. Last but not least this enables disconnected operation when using submodules, as all commits necessary for a successful "git submodule update -N" will have been fetched automatically. So we choose this mode as the default for fetch and pull. Before a new or changed ref from upstream is updated in update_local_ref() "git rev-list <new-sha1> --not --branches --remotes" is used to determine all newly fetched commits. These are then walked and diffed against their parent(s) to see if a submodule has been changed. If that is the case, its path is stored to be fetched after the superproject fetch is completed. Using the "--recurse-submodules" or the "--no-recurse-submodules" option disables the examination of the fetched refs because the result will be ignored anyway. There is currently no infrastructure for storing deleted and new submodules in the .git directory of the superproject. That's why fetch and pull for now only fetch submodules that are already checked out and are not renamed. In t7403 the "--no-recurse-submodules" argument had to be added to "git pull" to avoid failure because of the moved upstream submodule repo. Thanks-to: Jonathan Nieder <jrnieder@gmail.com> Thanks-to: Heiko Voigt <hvoigt@hvoigt.net> Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-10-13submodule sync: Update "submodule.<name>.url" for empty directoriesLibravatar Andreas Köhler1-1/+11
If a submodule directory has not been filled by "git submodule update" yet, then "git submodule sync" must still update the super-project's configuration for submodule.<name>.url. This situation occurs when switching between branches with a module from different urls and other branches without the submodule. Signed-off-by: Andreas Köhler <andi5.py@gmx.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-31Merge branch 'da/fix-submodule-sync-superproject-config'Libravatar Junio C Hamano1-0/+3
* da/fix-submodule-sync-superproject-config: submodule sync: Update "submodule.<name>.url"
2010-08-21t7403: add missing &&'sLibravatar Jens Lehmann1-2/+2
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-18submodule sync: Update "submodule.<name>.url"Libravatar David Aguilar1-0/+3
When "git submodule sync" synchronizes the repository URLs it only updates submodules' .git/config. However, the old URLs still exist in the super-project's .git/config. Update the super-project's configuration so that commands such as "git submodule update" use the URLs from .gitmodules. Signed-off-by: David Aguilar <davvid@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-10-02tests: add a testcase for "git submodule sync"Libravatar David Aguilar1-0/+64
This testcase ensures that upstream changes to submodule properties can be updated using the sync subcommand. This particular test changes the submodule URL upstream and uses the sync command to update an existing checkout. Signed-off-by: David Aguilar <davvid@gmail.com> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>