git/git-submodule.sh, branch v1.7.11

submodules: print "registered for path" message only once

2012-05-29T20:52:23Z

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: Nicolas Viennot and Sid Nair Reported-by: Heiko Voigt Signed-off-by: Jens Lehmann Signed-off-by: Junio C Hamano

Merge branch 'rj/submodule-mswin-path'

2012-04-23T20:01:49Z

By Ramsay Jones * rj/submodule-mswin-path: git-submodule.sh: Don't use $path variable in eval_gettext string

git-submodule.sh: Don't use $path variable in eval_gettext string

2012-04-18T20:05:33Z

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 df599e9 (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: Ramsay Jones Acked-by: Jens Lehmann Tested-by: Johannes Sixt Signed-off-by: Junio C Hamano

Avoid bug in Solaris xpg4/sed as used in submodule

2012-04-09T21:49:32Z

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: Ben Walton Signed-off-by: Junio C Hamano

submodules: fix ambiguous absolute paths under Windows

2012-03-05T05:22:46Z

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: Johannes Sixt Signed-off-by: Junio C Hamano

submodules: refactor computation of relative gitdir path

2012-03-05T05:22:35Z

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 Signed-off-by: Junio C Hamano

submodules: always use a relative path from gitdir to work tree

2012-03-05T05:20:27Z

Since recently a submodule with name has its git directory in the .git/modules/ 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 Signed-off-by: Junio C Hamano

submodules: always use a relative path to gitdir

2012-03-05T05:19:41Z

Since recently a submodule with name has its git directory in the .git/modules/ 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/ 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 Signed-off-by: Jens Lehmann Signed-off-by: Junio C Hamano

submodule add: fix breakage when re-adding a deep submodule

2012-01-24T22:18:18Z

Since recently a submodule with name has its git directory in the .git/modules/ 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/ 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 Signed-off-by: Jens Lehmann Signed-off-by: Junio C Hamano

Merge branch 'tc/submodule-clone-name-detection'

2011-10-26T23:16:32Z

* tc/submodule-clone-name-detection: submodule::module_clone(): silence die() message from module_name() submodule: whitespace fix