- 18 6月, 2013 2 次提交
-
-
由 John Keeping 提交于
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: NJohn Keeping <john@keeping.me.uk> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 John Keeping 提交于
When --recursive was added to "submodule foreach" in commit 15fc56a8 (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: NJohn Keeping <john@keeping.me.uk> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 02 4月, 2013 1 次提交
-
-
由 Jens Lehmann 提交于
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: NPhil Hord <phil.hord@gmail.com> Signed-off-by: NJens Lehmann <Jens.Lehmann@web.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 01 4月, 2013 1 次提交
-
-
由 René Scharfe 提交于
In addition to "--summary-limit <n>" support the form "--summary-limit=<n>", for consistency with other parameters and commands. Signed-off-by: NRene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 05 3月, 2013 1 次提交
-
-
由 Jens Lehmann 提交于
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: NJens Lehmann <Jens.Lehmann@web.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 04 3月, 2013 1 次提交
-
-
由 William Entriken 提交于
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: NWilliam Entriken <github.com@phor.net> Acked-by: NJens Lehmann <Jens.Lehmann@web.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 17 1月, 2013 1 次提交
-
-
由 Junio C Hamano 提交于
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: NJunio C Hamano <gitster@pobox.com> Signed-off-by: NRalf Thielow <ralf.thielow@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 20 12月, 2012 2 次提交
-
-
由 W. Trevor King 提交于
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: NW. Trevor King <wking@tremily.us> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 W. Trevor King 提交于
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 f030c96d 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: NW. Trevor King <wking@tremily.us> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 12 12月, 2012 1 次提交
-
-
由 W. Trevor King 提交于
Several submodule configuration variables (e.g. fetchRecurseSubmodules) are read from .gitmodules with local overrides from the usual git config files. This shell function mimics that logic to help initialize configuration variables in git-submodule.sh. Signed-off-by: NW. Trevor King <wking@tremily.us> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 29 10月, 2012 2 次提交
-
-
由 Phil Hord 提交于
The submodule sync command was somehow left out when --recursive was added to the other submodule commands. Teach sync to handle the --recursive switch by recursing when we're in a submodule we are sync'ing. Change the report during sync to show submodule-path instead of submodule-name to be consistent with the other submodule commands and to help recursed paths make sense. Signed-off-by: NPhil Hord <hordp@cisco.com> Acked-By: NJens Lehmann <Jens.Lehmann@web.de> Signed-off-by: NJeff King <peff@peff.net>
-
由 Jens Lehmann 提交于
When renaming orig_args to orig_flags in 98dbe63d (submodule: only preserve flags across recursive status/update invocations) the call site of the recursive cmd_status was forgotten. At that place orig_args is still passed into the recursion, which is always empty since then. This did not break anything because the orig_flags logic is not needed at all when a function from the submodule script is called with eval, as that inherits all the variables set by the option parsing done in the first level of the recursion. Now that we know that orig_flags and orig_args aren't needed at all, let's just remove them from cmd_status(). Thanks-to: Phil Hord <hordp@cisco.com> Signed-off-by: NJens Lehmann <Jens.Lehmann@web.de> Signed-off-by: NJeff King <peff@peff.net>
-
- 26 10月, 2012 1 次提交
-
-
由 Stefan Zager 提交于
Doing a shift here is wrong because there is no extra argument to consume when "--reference=<repo>" is used (note the '=' instead of a space). Signed-off-by: NStefan Zager <szager@google.com> Signed-off-by: NJeff King <peff@peff.net>
-
- 25 10月, 2012 1 次提交
-
-
由 W. Trevor King 提交于
Use "-b <branch>" instead of "-b branch". This brings the usage strings in line with other options, e.g. "--reference <repository>". Signed-off-by: NW. Trevor King <wking@tremily.us> Signed-off-by: NJeff King <peff@peff.net>
-
- 01 10月, 2012 1 次提交
-
-
由 Jens Lehmann 提交于
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: NJonathan Johnson <me@jondavidjohn.com> Signed-off-by: NJens Lehmann <Jens.Lehmann@web.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 30 9月, 2012 1 次提交
-
-
由 Jens Lehmann 提交于
"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: NJonathan Johnson <me@jondavidjohn.com> Signed-off-by: NJens Lehmann <Jens.Lehmann@web.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 26 9月, 2012 1 次提交
-
-
由 Ramkumar Ramachandra 提交于
"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: NRamkumar Ramachandra <artagnon@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 25 8月, 2012 1 次提交
-
-
由 Stefan Zager 提交于
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: NStefan Zager <szager@google.com> Acked-by: NJens Lehmann <Jens.Lehmann@web.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 15 8月, 2012 1 次提交
-
-
由 Heiko Voigt 提交于
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: NHeiko Voigt <hvoigt@hvoigt.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 27 7月, 2012 1 次提交
-
-
由 Jiang Xin 提交于
Gettext message in a shell script should not start with '-', one workaround is adding '--' between gettext and the message, like: gettext -- "--exec option ..." But due to a bug in the xgettext extraction, xgettext can not extract the actual message for this case. Rewriting the message is a simpler and better solution. Reported-by: NVincent van Ravesteijn <vfr@lyx.org> Signed-off-by: NJiang Xin <worldhello.net@gmail.com> Signed-off-by: NÆvar Arnfjörð Bjarmason <avarab@gmail.com> Reviewed-by: NStefano Lattarini <stefano.lattarini@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 26 7月, 2012 1 次提交
-
-
由 Daniel Graña 提交于
The combination of GIT_DIR and GIT_WORK_TREE can be used to manage files in one directory hierarchy while keeping the repository that keeps track of them outside the directory hierarchy. For example: git init --bare /path/to/there alias dotfiles="GIT_DIR=/path/to/there GIT_WORK_TREE=/path/to/here git" cd /path/to/here dotfiles add file dotfiles commit -a -m "add /path/to/here/file" ... lets you manage files under /path/to/here/ in the repository located at /path/to/there. git-submodule however fails to add submodules, as it is confused by GIT_DIR and GIT_WORK_TREE environment variables when it tries to work in the submodule, like so: dotfiles submodule add http://path.to/submodule fatal: working tree '/path/to/here' already exists. Simply unsetting the environment where the command works on the submodule is sufficient to fix this, as it has set things up so that GIT_DIR and GIT_WORK_TREE do not even have to point at the repository and the working tree of the submodule. Signed-off-by: NDaniel Graña <dangra@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 13 7月, 2012 1 次提交
-
-
由 Jens Lehmann 提交于
Since 69c30517 (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: NBob Halley <halley@play-bow.org> Signed-off-by: NJens Lehmann <Jens.Lehmann@web.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 26 6月, 2012 1 次提交
-
-
由 Michał Górny 提交于
Signed-off-by: NMichał Górny <mgorny@gentoo.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 07 6月, 2012 2 次提交
-
-
由 Jon Seymour 提交于
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: NJon Seymour <jon.seymour@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jon Seymour 提交于
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: NJon Seymour <jon.seymour@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 30 5月, 2012 1 次提交
-
-
由 Jens Lehmann 提交于
Since 2cd9de3e (submodule add: always initialize .git/config entry) the message "Submodule '\$name' (\$url) registered for path '\$sm_path'" is printed every time cmd_init() is called, e.g. each time "git submodule update" is used with the --init option. This was not intended and leads to bogus output which can confuse users and build systems. Apart from that the $url variable was not set after the first run which did the actual initialization and only "()" was printed in subsequent runs where "($url)" was meant to inform the user about the upstream repo. Fix that by moving the say command in question into the if block where the url is initialized, restoring the behavior that was in place before the 2cd9de3e commit. While at it also remove the comment which still describes the logic used before 2cd9de3e and add a comment about how things work now. Reported-by: NNicolas Viennot and Sid Nair <nicolas@viennot.com> Reported-by: NHeiko Voigt <hvoigt@hvoigt.net> Signed-off-by: NJens Lehmann <Jens.Lehmann@web.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 19 4月, 2012 1 次提交
-
-
由 Ramsay Jones 提交于
The eval_gettext (and eval_gettextln) i18n shell functions call git-sh-i18n--envsubst to process the variable references in the string parameter. Unfortunately, environment variables are case insensitive on windows, which leads to failure on cygwin when eval_gettext exports $path. Commit df599e96 (Windows: teach getenv to do a case-sensitive search, 06-06-2011) attempts to solve this problem on MinGW by overriding the system getenv() function to allow git-sh-i18n--envsubst to read $path rather than $PATH from the environment. However, this commit does not address cygwin at all and, furthermore, does not fix all problems on MinGW. In particular, when executing test #38 in t7400-submodule-basic.sh, an 'git-sh-i18n-envsubst.exe - Unable To Locate Component' dialog pops up saying that the application "failed to start because libiconv2.dll was not found." After studying the voluminous trace output from the process monitor, it is clear that the system is attempting to use $path, rather than $PATH, to search for the DLL file. (Note that, after dismissing the dialog, the test passes anyway!) As an alternative, we finesse the problem by renaming the $path variable to $sm_path (submodule path). This fixes the problem on MinGW along with all test failures on cygwin (t7400.{7,32,34}, t7406.3 and t7407.{2,6}). We note that the foreach subcommand provides $path to user scripts (ie it is part of the API), so we can't simply rename it to $sm_path. Signed-off-by: NRamsay Jones <ramsay@ramsay1.demon.co.uk> Acked-by: NJens Lehmann <Jens.Lehmann@web.de> Tested-by: NJohannes Sixt <j6t@kdbg.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 10 4月, 2012 1 次提交
-
-
由 Ben Walton 提交于
The sed provided by Solaris in /usr/xpg4/bin has a bug whereby an unanchored regex using * for zero or more repetitions sees two separate matches fed to the substitution engine in some cases. This is evidenced by: $ for sed in /usr/xpg4/bin/sed /usr/bin/sed /opt/csw/gnu/sed; do \ echo 'ab' | $sed -e 's|[a]*|X|g'; \ done XXbX XbX XbX This bug was triggered during a git submodule clone operation as exercised in the setup stage of t5526-fetch-submodules when using the default SANE_TOOL_PATH for Solaris. It led to paths such as ..../.. being used in the submodule .git gitdir reference. Using the expression 's|\([^/]*\(/*\)\)|..\2|g' provides the desired result with all three three tested sed implementations but is harder to read. As we do not need to handle fully qualified paths though, the expression could actually be [^/]+ which isn't properly handled either. Instead, use [^/][^/]*, as suggested by Andreas Schwab, which works on all three tested sed implementations. The new expression is semantically different than the original one. It will not place a leading '..' on a fully qualified path as the original expression did. All of the paths being passed through this regex are relative and did not rely on this behaviour so it's a safe change. Signed-off-by: NBen Walton <bwalton@artsci.utoronto.ca> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 05 3月, 2012 4 次提交
-
-
由 Johannes Sixt 提交于
Under Windows the "git rev-parse --git-dir" and "pwd" commands may return either drive-letter-colon or POSIX style paths. This makes module_clone() behave badly because it expects absolute paths to always start with a '/'. Fix that by always converting the "c:/" notation into "/c/" when computing the relative paths from gitdir to the submodule work tree and back. Signed-off-by: NJohannes Sixt <j6t@kdbg.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jens Lehmann 提交于
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: NJens Lehmann <Jens.Lehmann@web.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jens Lehmann 提交于
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: NJens Lehmann <Jens.Lehmann@web.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Jens Lehmann 提交于
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: NAntony Male <antony.male@gmail.com> Signed-off-by: NJens Lehmann <Jens.Lehmann@web.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 25 1月, 2012 1 次提交
-
-
由 Jens Lehmann 提交于
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: NJehan Bing <jehan@orb.com> Signed-off-by: NJens Lehmann <Jens.Lehmann@web.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 22 10月, 2011 2 次提交
-
-
由 Tay Ray Chuan 提交于
The die() message that may occur in module_name() is not really relevant to the user when called from module_clone(); the latter handles the "failure" (no submodule mapping) anyway. Analysis of other callsites is left to future work. Acked-by: NJens Lehmann <Jens.Lehmann@web.de> Signed-off-by: NTay Ray Chuan <rctay89@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Tay Ray Chuan 提交于
Replace SPs with TAB. Signed-off-by: NTay Ray Chuan <rctay89@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 23 8月, 2011 1 次提交
-
-
由 Fredrik Gustafsson 提交于
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: NFredrik Gustafsson <iveqy@iveqy.com> Mentored-by: NJens Lehmann <Jens.Lehmann@web.de> Mentored-by: NHeiko Voigt <hvoigt@hvoigt.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 12 8月, 2011 2 次提交
-
-
由 Heiko Voigt 提交于
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: NHeiko Voigt <hvoigt@hvoigt.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Heiko Voigt 提交于
Lets always initialize the 'update_module' variable with the final value. This way we allow code which wants to check this configuration early to do so right in the beginning of cmd_update(). Signed-off-by: NHeiko Voigt <hvoigt@hvoigt.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 09 8月, 2011 1 次提交
-
-
由 Jon Seymour 提交于
Signed-off-by: NJon Seymour <jon.seymour@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 29 7月, 2011 1 次提交
-
-
由 Jens Lehmann 提交于
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: NDaniel Holtmann-Rice <flyingtabmow@gmail.com> Signed-off-by: NJens Lehmann <Jens.Lehmann@web.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-