summaryrefslogtreecommitdiff
path: root/t/t7400-submodule-basic.sh
AgeCommit message (Collapse)AuthorFilesLines
2016-03-22submodule: fix regression for deinit without submodulesLibravatar Stefan Beller1-0/+13
Per Cederqvist wrote: > It used to be possible to run > > git submodule deinit -f . > > to remove any submodules, no matter how many submodules you had. That > is no longer possible in projects that don't have any submodules at > all. The command will fail with: > > error: pathspec '.' did not match any file(s) known to git. This regression was introduced in 74703a1e4dfc (submodule: rewrite `module_list` shell function in C, 2015-09-02), as we changed the order of checking in new module listing to first check whether it is a gitlin before feeding it to match_pathspec(). It used to be that a pathspec that does not match any path were diagnosed as an error, but the new code complains for a pathspec that does not match any submodule path. Arguably the new behaviour may give us a better diagnosis, but that is inconsistent with the suggestion "deinit" gives, and also this was an unintended accident. The new behaviour hopefully can be redesigned and implemented better in future releases, but for now, switch these two checks to restore the same behavior as before. In an empty repository, giving the pathspec '.' will still get the same "did not match" error, but that is the same bug we had before 1.7.0. Reported-by: Per Cederqvist <cederp@opera.com> Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-24submodule helper list: respect correct path prefixLibravatar Stefan Beller1-0/+25
This is a regression introduced by 74703a1e4d (submodule: rewrite `module_list` shell function in C, 2015-09-02). Add a test to ensure we list the right submodule when giving a specific pathspec. Reported-By: Caleb Jorden <cjorden@gmail.com> Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-20t: fix trivial &&-chain breakageLibravatar Jeff King1-2/+2
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>
2015-02-22Merge branch 'ps/submodule-sanitize-path-upon-add'Libravatar Junio C Hamano1-0/+17
"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-0/+17
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-03-21t: prefer "git config --file" to GIT_CONFIGLibravatar Jeff King1-3/+2
Doing: GIT_CONFIG=foo git config ... is equivalent to: git config --file=foo ... The latter is easier to read and slightly less error-prone, because of issues with one-shot variables and shell functions (e.g., you cannot use the former with test_must_fail). Note that we explicitly leave one case in t1300 which checks the same operation on both GIT_CONFIG and "git config --file". They are equivalent in the code these days, but this will make sure it remains so. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-17Merge branch 'jk/trailing-slash-in-pathspec'Libravatar Junio C Hamano1-2/+4
Code refactoring. * jk/trailing-slash-in-pathspec: reset: handle submodule with trailing slash rm: re-use parse_pathspec's trailing-slash removal
2013-09-17Merge branch 'tb/precompose-autodetect-fix'Libravatar Junio C Hamano1-1/+0
On MacOS X, we detected if the filesystem needs the "pre-composed unicode strings" workaround, but did not automatically enable it. Now we do. * tb/precompose-autodetect-fix: Set core.precomposeunicode to true on e.g. HFS+
2013-09-13reset: handle submodule with trailing slashLibravatar John Keeping1-2/+4
When using tab-completion, a directory path will often end with a trailing slash which currently confuses "git reset" when dealing with submodules. Now that we have parse_pathspec we can easily handle this by simply adding the PATHSPEC_STRIP_SUBMODULE_SLASH_CHEAP flag. To do this, we need to move the read_cache() call before the parse_pathspec() call. All of the existing paths through cmd_reset() that do not die early already call read_cache() at some point, so there is no performance impact to doing this in the common case. Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-09Merge branch 'jl/submodule-mv'Libravatar Junio C Hamano1-10/+4
"git mv A B" when moving a submodule A does "the right thing", inclusing relocating its working tree and adjusting the paths in the .gitmodules file. * jl/submodule-mv: (53 commits) rm: delete .gitmodules entry of submodules removed from the work tree mv: update the path entry in .gitmodules for moved submodules submodule.c: add .gitmodules staging helper functions mv: move submodules using a gitfile mv: move submodules together with their work trees rm: do not set a variable twice without intermediate reading. t6131 - skip tests if on case-insensitive file system parse_pathspec: accept :(icase)path syntax pathspec: support :(glob) syntax pathspec: make --literal-pathspecs disable pathspec magic pathspec: support :(literal) syntax for noglob pathspec kill limit_pathspec_to_literal() as it's only used by parse_pathspec() parse_pathspec: preserve prefix length via PATHSPEC_PREFIX_ORIGIN parse_pathspec: make sure the prefix part is wildcard-free rename field "raw" to "_raw" in struct pathspec tree-diff: remove the use of pathspec's raw[] in follow-rename codepath remove match_pathspec() in favor of match_pathspec_depth() remove init_pathspec() in favor of parse_pathspec() remove diff_tree_{setup,release}_paths convert common_prefix() to use struct pathspec ...
2013-09-04Merge branch 'jl/some-submodule-config-are-not-boolean'Libravatar Junio C Hamano1-0/+10
* jl/some-submodule-config-are-not-boolean: avoid segfault on submodule.*.path set to an empty "true"
2013-08-27Set core.precomposeunicode to true on e.g. HFS+Libravatar Torsten Bögershausen1-1/+0
When core.precomposeunicode was introduced in 76759c7d, it was set to false on a unicode decomposing file system like HFS+ to be compatible with older versions of Git. The Mac OS users need to find out that this configuration exist and change it manually from false to true. A smoother workflow can be achieved, so set core.precomposeunicode to true on a decomposing file system. Signed-off-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-08-19avoid segfault on submodule.*.path set to an empty "true"Libravatar Jharrod LaFon1-0/+10
Git fails due to a segmentation fault if a submodule path is empty. Here is an example .gitmodules that will cause a segmentation fault: [submodule "foo-module"] path url = http://host/repo.git $ git status Segmentation fault (core dumped) This is because the parsing of "submodule.*.path" is not prepared to see a value-less "true" and assumes that the value is always non-NULL (parsing of "ignore" has the same problem). Fix it by checking the NULL-ness of value and complain with config_error_nonbool(). Signed-off-by: Jharrod LaFon <jlafon@eyesopen.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-08-06rm: delete .gitmodules entry of submodules removed from the work treeLibravatar Jens Lehmann1-10/+4
Currently using "git rm" on a submodule removes the submodule's work tree from that of the superproject and the gitlink from the index. But the submodule's section in .gitmodules is left untouched, which is a leftover of the now removed submodule and might irritate users (as opposed to the setting in .git/config, this must stay as a reminder that the user showed interest in this submodule so it will be repopulated later when an older commit is checked out). Let "git rm" help the user by not only removing the submodule from the work tree but by also removing the "submodule.<submodule name>" section from the .gitmodules file and stage both. This doesn't happen when the "--cached" option is used, as it would modify the work tree. This also silently does nothing when no .gitmodules file is found and only issues a warning when it doesn't have a section for this submodule. This is because the user might just use plain gitlinks without the .gitmodules file or has already removed the section by hand before issuing the "git rm" command (in which case the warning reminds him that rm would have done that for him). Only when .gitmodules is found and contains merge conflicts the rm command will fail and tell the user to resolve the conflict before trying again. Also extend the man page to inform the user about this new feature. While at it promote the submodule sub-section to a chapter as it made not much sense under "REMOVING FILES THAT HAVE DISAPPEARED FROM THE FILESYSTEM". In t7610 three uses of "git rm submod" had to be replaced with "git rm --cached submod" because that test expects .gitmodules and the work tree to stay untouched. Also in t7400 the tests for the remaining settings in the .gitmodules file had to be changed to assert that these settings are missing. Signed-off-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-0/+16
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-0/+15
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-06-30Merge branch 'jk/submodule-subdirectory-ok'Libravatar Junio C Hamano1-0/+80
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-0/+15
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-20Merge branch 'fc/show-non-empty-errors-in-test'Libravatar Junio C Hamano1-3/+3
* fc/show-non-empty-errors-in-test: test: test_must_be_empty helper
2013-06-20t7400: test of UTF-8 submodule names pass under Mac OSLibravatar Torsten Bögershausen1-8/+11
submodules with names using UTF-8 need core.precomposeunicode true under Mac OS X, set it in the test case. Improve the portability: - Not all shells on all OS may understand literal UTF-8 strings. - Use a help variable filled by printf, as we do it in e.g. t0050. "strange names" can be called UTF-8, rephrase the heading. While at it, unbreak &&-chain in the test, and use test_config. Signed-off-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-17submodule: drop the top-level requirementLibravatar John Keeping1-0/+80
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-14handle multibyte characters in nameLibravatar Fredrik Gustafsson1-0/+12
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-06-09test: test_must_be_empty helperLibravatar Junio C Hamano1-3/+3
There are quite a lot places where an output file is expected to be empty, and we fail the test when it is not. The output from running the test script with -i -v can be helped if we showed the unexpected contents at that point. We could of course do >expected.empty && test_cmp expected.empty actual but this is commmon enough to be done with a dedicated helper. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-05Merge branch 'jl/submodule-deinit'Libravatar Junio C Hamano1-5/+16
A finishing touch to the new topic in 1.8.3. * jl/submodule-deinit: submodule deinit: clarify work tree removal message
2013-04-01submodule deinit: clarify work tree removal messageLibravatar Jens Lehmann1-5/+16
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-03-25Merge branch 'jl/submodule-deinit'Libravatar Junio C Hamano1-0/+100
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-04submodule: add 'deinit' commandLibravatar Jens Lehmann1-0/+100
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>
2012-12-19submodule add: If --branch is given, record it in .gitmodulesLibravatar W. Trevor King1-0/+1
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-10-29Merge branch 'jl/submodule-add-by-name'Libravatar Jeff King1-0/+75
If you remove a submodule, in order to keep the repository so that "git checkout" to an older commit in the superproject history can resurrect the submodule, the real repository will stay in $GIT_DIR of the superproject. A later "git submodule add $path" to add a different submodule at the same path will fail. Diagnose this case a bit better, and if the user really wants to add an unrelated submodule at the same path, give the "--name" option to give it a place in $GIT_DIR of the superproject that does not conflict with the original submodule. * jl/submodule-add-by-name: submodule add: Fail when .git/modules/<name> already exists unless forced Teach "git submodule add" the --name option
2012-09-30submodule add: Fail when .git/modules/<name> already exists unless forcedLibravatar Jens Lehmann1-0/+30
When adding a new submodule it can happen that .git/modules/<name> already contains a submodule repo, e.g. when a submodule is removed from the work tree and another submodule is added at the same path. But then the work tree of the submodule will be populated using the existing repository and not the one the user provided, which results in an incorrect work tree. On the other hand the user might reactivate a submodule removed earlier, then reusing that .git directory is the Right Thing to do. As git can't decide what is the case, error out and tell the user she should use either use a different name for the submodule with the "--name" option or can reuse the .git directory for the newly added submodule by providing the --force option (which only makes sense when the upstream matches, so the error message lists all remotes of .git/modules/<name>). In one test in t7406 the --force option had to be added to "git submodule add", as that test re-adds a formerly removed submodule. Reported-by: Jonathan Johnson <me@jondavidjohn.com> Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-29Merge branch 'rr/maint-submodule-unknown-cmd'Libravatar Junio C Hamano1-2/+2
* rr/maint-submodule-unknown-cmd: submodule: if $command was not matched, don't parse other args
2012-09-29Teach "git submodule add" the --name optionLibravatar Jens Lehmann1-0/+45
"git submodule add" initializes the name of a submodule to its path. This was ok as long as the .git directory lived inside the submodule's work tree, but since 1.7.8 it is stored in the .git/modules/<name> directory of the superproject, making the submodule name survive the removal of the submodule's work tree. This leads to problems when the user tries to add a different submodule at the same path - and thus the same name - later, as that will happily try to restore the submodule from the old repository instead of the one the user specified and will lead to a checkout of the wrong repository. Add the new "--name" option to let the user provide a name for the submodule. This enables the user to solve this conflict without having to remove .git/modules/<name> by hand (which is no viable solution as it makes it impossible to checkout a commit that records the old submodule and populate it, as that will still check out the new submodule for the same reason). To achieve that the submodule's name is added to the parameter list of the module_clone() helper function. This makes it possible to remove the call of module_name() there because both callers of module_clone() already know the name and can provide it as argument number two. Reported-by: Jonathan Johnson <me@jondavidjohn.com> Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-25submodule: if $command was not matched, don't parse other argsLibravatar Ramkumar Ramachandra1-2/+2
"git submodule" command DWIMs the command line and assumes a unspecified action word for 'status' action. This is a UI mistake that leads to a confusing behaviour. A mistyped command name is instead treated as a request for 'status' of the submodule with that name, e.g. $ git submodule show error: pathspec 'show' did not match any file(s) known to git. Did you forget to 'git add'? Stop DWIMming an unknown or mistyped subcommand name as pathspec given to unspelled "status" subcommand. "git submodule" without any argument is still interpreted as "git submodule status", but its value is questionable. Adjust t7400 to match, and stop advertising the default subcommand being 'status' which does not help much in practice, other than promoting laziness and confusion. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-29Merge branch 'hv/submodule-path-unmatch'Libravatar Junio C Hamano1-4/+22
* hv/submodule-path-unmatch: Let submodule command exit with error status if path does not exist
2012-08-14Let submodule command exit with error status if path does not existLibravatar Heiko Voigt1-4/+22
Various subcommands of the "git submodule" command exited with 0 status even though the path given by the user did not exist. The reason behind that was that they all pipe the output of module_list into the while loop which then does the action on the paths specified by the commandline. Since the exit code of the command on the upstream side of the pipe is ignored by the shell, the status code of "ls-files --error-unmatch" nor "module_list" was not propagated. In case ls-files returns with an error code, we write a special string that is not possible in non error situations, and no other output, so that the downstream can detect the error and die with an error code. The error message that there is an unmatched pathspec comes through stderr directly from ls-files. So the user still gets a hint whats going on. Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-06-14t7400: avoid path mangling issuesLibravatar Johannes Sixt1-3/+8
A recently introduced test uses an absolute path. But when run on Windows using the MSYS bash, such a path is mangled into a Windows style path when it is passed to 'git config'. The subsequent 'test' then compares the mangled path to the unmangled version and reports a failure. A path beginning with two slashes denotes a network directory (//server/share path) and is not mangled. Use that trick to side-step the issue. Just in case that 'git submodule init' regresses in such a way that it accesses the URL, use a path name that is unlikely to exist on POSIX systems, and that cannot be a server name on Windows. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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-03submodule: document failure to handle relative superproject origin URLsLibravatar Jon Seymour1-0/+34
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>
2012-06-03submodule: additional regression tests for relative URLsLibravatar Jon Seymour1-3/+107
Some additional tests are added to support regression testing of the changes in the remainder of the series. We also add a pristine copy of .gitmodules in anticipation of this being required by later tests. Signed-off-by: Jon Seymour <jon.seymour@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-11tests: modernise style: more uses of test_line_countLibravatar Stefano Lattarini1-1/+1
Prefer: test_line_count <OP> COUNT FILE over: test $(wc -l <FILE) <OP> COUNT (or similar usages) in several tests. Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-03-04submodules: always use a relative path from gitdir to work treeLibravatar Jens Lehmann1-0/+20
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. To make that work the git directory has the core.worktree configuration set in its config file to point back to the work tree. That core.worktree is an absolute path set by the initial clone of the submodule. A relative path is preferable here because it allows the superproject to be moved around without invalidating that setting, so compute and set that relative path after cloning or reactivating the submodule. This also fixes a bug when moving a submodule around inside the superproject, as the current code forgot to update the setting to the new submodule work tree location. Enhance t7400 to ensure that future versions won't re-add absolute paths by accident and that moving a superproject won't break submodules. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-03-04submodules: always use a relative path to gitdirLibravatar Jens Lehmann1-0/+2
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 submodule git directory needs to be cloned because it is not found in .git/modules/<name> the clone command will write an absolute path into the gitfile. When no clone is necessary the git directory will be reactivated by the git-submodule.sh script by writing a relative path into the gitfile. This is inconsistent, as the behavior depends on the submodule having been cloned before into the .git/modules of the superproject. A relative path is preferable here because it allows the superproject to be moved around without invalidating the gitfile. We do that by always writing the relative path into the gitfile, which overwrites the absolute path the clone command may have written there. This is only the first step to make superprojects movable again like they were before the separate-git-dir approach was introduced. The second step is to use a relative path in core.worktree too. Enhance t7400 to ensure that future versions won't re-add absolute paths by accident. While at it also replace an if/else construct evaluating the presence of the 'reference' option with a single line of bash code. Reported-by: Antony Male <antony.male@gmail.com> Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-10Merge branch 'fg/submodule-git-file-git-dir'Libravatar Junio C Hamano1-2/+2
* fg/submodule-git-file-git-dir: Move git-dir for submodules rev-parse: add option --resolve-git-dir <path> Conflicts: cache.h git-submodule.sh
2011-08-16rev-parse: add option --resolve-git-dir <path>Libravatar Fredrik Gustafsson1-2/+2
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-08-08Merge branch 'jl/submodule-update-quiet'Libravatar Junio C Hamano1-2/+4
* jl/submodule-update-quiet: submodule: update and add must honor --quiet flag
2011-07-31Merge branch 'maint'Libravatar Junio C Hamano1-2/+4
* maint: Break down no-lstat() condition checks in verify_uptodate() t7400: fix bogus test failure with symlinked trash Documentation: clarify the invalidated tree entry format
2011-07-31t7400: fix bogus test failure with symlinked trashLibravatar Jeff King1-2/+4
One of the tests in t7400 fails if the trash directory has a symlink anywhere in its path. E.g.: $ mkdir /tmp/git-test $ mkdir /tmp/git-test/real $ ln -s real /tmp/git-test/link $ ./t7400-submodule-basic --root=/tmp/git-test/real ... # passed all 44 test(s) $ ./t7400-submodule-basic --root=/tmp/git-test/link ... not ok - 41 use superproject as upstream when path is relative and no url is set there The failing test does: git submodule add ../repo relative && ... git submodule sync relative && test "$(git config submodule.relative.url)" = "$submodurl/repo" where $submodurl comes from the $TRASH_DIRECTORY the user gave us. However, git will resolve symlinks when converting the relative path into an absolute one, leading them to be textually different (even though they point to the same directory). Fix this by asking pwd to canonicalize the name of the trash directory for us. Signed-off-by: Jeff King <peff@peff.net> Acked-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-07-28submodule: update and add must honor --quiet flagLibravatar Jens Lehmann1-2/+4
When using the --quiet flag "git submodule update" and "git submodule add" didn't behave as the documentation stated. They printed progress output from the clone, even though they should only print error messages. Fix that by passing the -q flag to git clone in module_clone() when the GIT_QUIET variable is set. Two tests in t7400 have been modified to test that behavior. Reported-by: Daniel Holtmann-Rice <flyingtabmow@gmail.com> Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-07-22Merge branch 'jl/submodule-add-relurl-wo-upstream'Libravatar Junio C Hamano1-0/+10
* jl/submodule-add-relurl-wo-upstream: submodule add: clean up duplicated code submodule add: allow relative repository path even when no url is set submodule add: test failure when url is not configured in superproject Conflicts: git-submodule.sh
2011-06-06submodule add: allow relative repository path even when no url is setLibravatar Jens Lehmann1-2/+5
Adding a submodule with a relative repository path did only succeed when the superproject's default remote was set. But when that is unset, the superproject is its own authoritative upstream, so lets use its working directory as upstream instead. This allows users to set up a new superpoject where the submodules urls are configured relative to the superproject's upstream while its default remote can be configured later. Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>