summaryrefslogtreecommitdiff
path: root/t/t0060-path-utils.sh
AgeCommit message (Collapse)AuthorFilesLines
2016-02-17Merge branch 'js/mingw-tests'Libravatar Junio C Hamano1-0/+9
Test scripts have been updated to remove assumptions that are not portable between Git for POSIX and Git for Windows, or to skip ones with expectations that are not satisfiable on Git for Windows. * js/mingw-tests: (21 commits) gitignore: ignore generated test-fake-ssh executable mingw: do not bother to test funny file names mingw: skip a test in t9130 that cannot pass on Windows mingw: handle the missing POSIXPERM prereq in t9124 mingw: avoid illegal filename in t9118 mingw: mark t9100's test cases with appropriate prereqs t0008: avoid absolute path mingw: work around pwd issues in the tests mingw: fix t9700's assumption about directory separators mingw: skip test in t1508 that fails due to path conversion tests: turn off git-daemon tests if FIFOs are not available mingw: disable mkfifo-based tests mingw: accomodate t0060-path-utils for MSYS2 mingw: fix t5601-clone.sh mingw: let lstat() fail with errno == ENOTDIR when appropriate mingw: try to delete target directory before renaming mingw: prepare the TMPDIR environment variable for shell scripts mingw: factor out Windows specific environment setup Git.pm: stop assuming that absolute paths start with a slash mingw: do not trust MSYS2's MinGW gettext.sh ...
2016-02-03Merge branch 'js/dirname-basename'Libravatar Junio C Hamano1-0/+3
dirname() emulation has been added, as Msys2 lacks it. * js/dirname-basename: mingw: avoid linking to the C library's isalpha() t0060: loosen overly strict expectations t0060: verify that basename() and dirname() work as expected compat/basename.c: provide a dirname() compatibility function compat/basename: make basename() conform to POSIX Refactor skipping DOS drive prefixes
2016-01-27mingw: accomodate t0060-path-utils for MSYS2Libravatar Johannes Schindelin1-0/+9
On Windows, there are no POSIX paths, only Windows ones (an absolute Windows path looks like "C:\Program Files\Git\ReleaseNotes.html", under most circumstances, forward slashes are also allowed and synonymous to backslashes). So when a POSIX shell (such as MSYS2's Bash, which is used by Git for Windows to execute all those shell scripts that are part of Git) passes a POSIX path to test-path-utils.exe (which is not POSIX-aware), the path is translated into a Windows path. For example, /etc/profile becomes C:/Program Files/Git/etc/profile. This path translation poses a problem when passing the root directory as parameter to test-path-utils.exe, as it is not well defined whether the translated root directory should end in a slash or not. MSys1 stripped the trailing slash, but MSYS2 does not. Originally, the Git for Windows project patched MSYS2's runtime to accomodate Git's regression test, but we really should do it the other way round. To work with both of MSys1's and MSYS2's behaviors, we simply test what the current system does in the beginning of t0060-path-utils.sh and then adjust the expected longest ancestor length accordingly. It looks quite a bit tricky what we actually do in this patch: first, we adjust the expected length for the trailing slash we did not originally expect (subtracting one). So far, so good. But now comes the part where things work in a surprising way: when the expected length was 0, the prefix to match is the root directory. If the root directory is converted into a path with a trailing slash, however, we know that the logic in longest_ancestor_length() cannot match: to avoid partial matches of the last directory component, it verifies that the character after the matching prefix is a slash (but because the slash was part of the matching prefix, the next character cannot be a slash). So the return value is -1. Alas, this is exactly what the expected length is after subtracting the value of $rootslash! So we skip adding the $rootoff value in that case (and only in that case). Directories other than the root directory are handled fine (as they are specified without a trailing slash, something not possible for the root directory, and MSYS2 converts them into Windows paths that also lack trailing slashes), therefore we do not need any more special handling. Thanks to Ray Donnelly for his patient help with this issue. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-12t0060: verify that basename() and dirname() work as expectedLibravatar Johannes Schindelin1-0/+3
Unfortunately, some libgen implementations yield outcomes different from what Git expects. For example, mingw-w64-crt provides a basename() function, that shortens `path0/` to `path`! So let's verify that the basename() and dirname() functions we use conform to what Git expects. Derived-from-code-by: Ramsay Jones <ramsay@ramsayjones.plus.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-01refs: make refs/bisect/* per-worktreeLibravatar David Turner1-0/+5
We need the place we stick refs for bisects in progress to not be shared between worktrees. So we make the refs/bisect/ hierarchy per-worktree. The is_per_worktree_ref function and associated docs learn that refs/bisect/ is per-worktree, as does the git_path code in path.c The ref-packing functions learn that per-worktree refs should not be packed (since packed-refs is common rather than per-worktree). Since refs/bisect is per-worktree, logs/refs/bisect should be too. Signed-off-by: David Turner <dturner@twopensource.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-01path: optimize common dir checkingLibravatar David Turner1-0/+1
Instead of a linear search over common_list to check whether a path is common, use a trie. The trie search operates on path prefixes, and handles excludes. Signed-off-by: David Turner <dturner@twopensource.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-12-01git_path(): keep "info/sparse-checkout" per work-treeLibravatar Nguyễn Thái Ngọc Duy1-0/+1
Currently git_path("info/sparse-checkout") resolves to $GIT_COMMON_DIR/info/sparse-checkout in multiple worktree mode. It makes more sense for the sparse checkout patterns to be per worktree, so you can have multiple checkouts with different parts of the tree. With this, "git checkout --to <new>" on a sparse checkout will create <new> as a full checkout. Which is expected, it's how a new checkout is made. The user can reshape the worktree afterwards. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-12-01$GIT_COMMON_DIR: a new environment variableLibravatar Nguyễn Thái Ngọc Duy1-0/+16
This variable is intended to support multiple working directories attached to a repository. Such a repository may have a main working directory, created by either "git init" or "git clone" and one or more linked working directories. These working directories and the main repository share the same repository directory. In linked working directories, $GIT_COMMON_DIR must be defined to point to the real repository directory and $GIT_DIR points to an unused subdirectory inside $GIT_COMMON_DIR. File locations inside the repository are reorganized from the linked worktree view point: - worktree-specific such as HEAD, logs/HEAD, index, other top-level refs and unrecognized files are from $GIT_DIR. - the rest like objects, refs, info, hooks, packed-refs, shallow... are from $GIT_COMMON_DIR (except info/sparse-checkout, but that's a separate patch) Scripts are supposed to retrieve paths in $GIT_DIR with "git rev-parse --git-path", which will take care of "$GIT_DIR vs $GIT_COMMON_DIR" business. The redirection is done by git_path(), git_pathdup() and strbuf_git_path(). The selected list of paths goes to $GIT_COMMON_DIR, not the other way around in case a developer adds a new worktree-specific file and it's accidentally promoted to be shared across repositories (this includes unknown files added by third party commands) The list of known files that belong to $GIT_DIR are: ADD_EDIT.patch BISECT_ANCESTORS_OK BISECT_EXPECTED_REV BISECT_LOG BISECT_NAMES CHERRY_PICK_HEAD COMMIT_MSG FETCH_HEAD HEAD MERGE_HEAD MERGE_MODE MERGE_RR NOTES_EDITMSG NOTES_MERGE_WORKTREE ORIG_HEAD REVERT_HEAD SQUASH_MSG TAG_EDITMSG fast_import_crash_* logs/HEAD next-index-* rebase-apply rebase-merge rsync-refs-* sequencer/* shallow_* Path mapping is NOT done for git_path_submodule(). Multi-checkouts are not supported as submodules. Helped-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-12-01git_path(): be aware of file relocation in $GIT_DIRLibravatar Nguyễn Thái Ngọc Duy1-0/+19
We allow the user to relocate certain paths out of $GIT_DIR via environment variables, e.g. GIT_OBJECT_DIRECTORY, GIT_INDEX_FILE and GIT_GRAFT_FILE. Callers are not supposed to use git_path() or git_pathdup() to get those paths. Instead they must use get_object_directory(), get_index_file() and get_graft_file() respectively. This is inconvenient and could be missed in review (for example, there's git_path("objects/info/alternates") somewhere in sha1_file.c). This patch makes git_path() and git_pathdup() understand those environment variables. So if you set GIT_OBJECT_DIRECTORY to /foo/bar, git_path("objects/abc") should return /foo/bar/abc. The same is done for the two remaining env variables. "git rev-parse --git-path" is the wrapper for script use. This patch kinda reverts a0279e1 (setup_git_env: use git_pathdup instead of xmalloc + sprintf - 2014-06-19) because using git_pathdup here would result in infinite recursion: setup_git_env() -> git_pathdup("objects") -> .. -> adjust_git_path() -> get_object_directory() -> oops, git_object_directory is NOT set yet -> setup_git_env() I wanted to make git_pathdup_literal() that skips adjust_git_path(). But that won't work because later on when $GIT_COMMON_DIR is introduced, git_pathdup_literal("objects") needs adjust_git_path() to replace $GIT_DIR with $GIT_COMMON_DIR. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-02-04setup: don't dereference in-tree symlinks for absolute pathsLibravatar Martin Erik Werner1-1/+1
The prefix_path_gently() function currently applies real_path to everything if given an absolute path, dereferencing symlinks both outside and inside the work tree. This causes most high-level functions to misbehave when acting on symlinks given via absolute paths. For example $ git add /dir/repo/symlink attempts to add the target of the symlink rather than the symlink itself, which is usually not what the user intends to do. In order to manipulate symlinks in the work tree using absolute paths, symlinks should only be dereferenced outside the work tree. Modify the prefix_path_gently() to first normalize the path in order to make sure path levels are separated by '/', then pass the result to 'abspath_part_inside_repo' to find the part inside the work tree (without dereferencing any symlinks inside the work tree). For absolute paths, prefix_path_gently() did not, nor does now do, any actual prefixing, hence the result from abspath_part_in_repo() is returned as-is. Fixes t0060-82 and t3004-5. Signed-off-by: Martin Erik Werner <martinerikwerner@gmail.com> Reviewed-by: Duy Nguyen <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-02-04t0060: add tests for prefix_path when path begins with work treeLibravatar Martin Erik Werner1-0/+10
One edge-case that isn't currently checked in the tests is the beginning of the path matching the work tree, despite the target not actually being the work tree, for example: path = /dir/repoa work_tree = /dir/repo should fail since the path is outside the repo. However, if /dir/repoa is in fact a symlink that points to /dir/repo, it should instead succeed. Add two tests covering these cases, since they might be potential regression points. Signed-off-by: Martin Erik Werner <martinerikwerner@gmail.com> Reviewed-by: Duy Nguyen <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-02-04t0060: add test for prefix_path when path == work treeLibravatar Martin Erik Werner1-0/+6
The current behaviour of prefix_path is to return an empty string if prefixing and absolute path that only contains exactly the work tree. This behaviour is a potential regression point. Signed-off-by: Martin Erik Werner <martinerikwerner@gmail.com> Reviewed-by: Duy Nguyen <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-02-04t0060: add test for prefix_path on symlinks via absolute pathsLibravatar Martin Erik Werner1-0/+5
When symlinks in the working tree are manipulated using the absolute path, git dereferences them, and tries to manipulate the link target instead. This applies to most high-level commands but prefix_path is the common denominator for all of them. Add a known-breakage tests using the prefix_path function, which currently uses real_path, causing the dereference. Signed-off-by: Martin Erik Werner <martinerikwerner@gmail.com> Reviewed-by: Duy Nguyen <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-10-28Merge branch 'jx/relative-path-regression-fix'Libravatar Junio C Hamano1-28/+32
* jx/relative-path-regression-fix: Use simpler relative_path when set_git_dir relative_path should honor dos-drive-prefix test: use unambigous leading path (/foo) for MSYS
2013-10-14path-utils test: rename mingw_path function to print_pathLibravatar Sebastian Schuberth1-2/+2
mingw_path was introduced in abd4284 to output a mangled path as it is passed as an argument to main(). But the name is misleading because mangling does not come from MinGW, but from MSYS [1]. As abd4284 does not introduce any MSYS or MinGW specific code but just prints out argv[2] as it is passed to main(), give the function the more generic and less confusing name "print_path". [1] http://www.mingw.org/wiki/Posix_path_conversion Signed-off-by: Sebastian Schuberth <sschuberth@gmail.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
2013-10-14relative_path should honor dos-drive-prefixLibravatar Jiang Xin1-0/+4
Tvangeste found that the "relative_path" function could not work properly on Windows if "in" and "prefix" have DOS drive prefix (such as "C:/windows"). ($gmane/234434) E.g., When execute: test-path-utils relative_path "C:/a/b" "D:/x/y", should return "C:/a/b", but returns "../../C:/a/b", which is wrong. So make relative_path honor DOS drive prefix, and add test cases for it in t0060. Reported-by: Tvangeste <i.4m.l33t@yandex.ru> Helped-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Jiang Xin <worldhello.net@gmail.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
2013-10-14test: use unambigous leading path (/foo) for MSYSLibravatar Jiang Xin1-28/+28
In test cases for relative_path, path with one leading character (such as /a, /x) may be recogonized as "a:/" or "x:/" if there is such DOS drive on MSYS platform. Use an umambigous leading path "/foo" instead. Also change two leading slashes (//) to three leading slashes (///), otherwize it will be recognized as UNC name on MSYS platform. Signed-off-by: Jiang Xin <worldhello.net@gmail.com> Acked-by: Sebastian Schuberth <sschuberth@gmail.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
2013-06-26test: run testcases with POSIX absolute paths on WindowsLibravatar Jiang Xin1-21/+23
Some test cases are skipped on Windows by marking with POSIX prereq. This is because arguments look like absolute paths (such as /a/b) for regular Windows programs (*.exe executables, no bash scripts) are changed to Windows paths (like C:/msysgit/a/b). There is no cygpath nor equivalent on msysGit, but it is easy to write one. New subcommand "mingw_path" is added in test-path-utils, so that we can get the expected absolute paths on Windows. E.g. COMMAND LINE Linux output Windows output ================================== ============ =============== test-path-utils mingw_path / / C:/msysgit test-path-utils mingw_path /a/b/ /a/b/ C:/msysgit/a/b/ With this utility, most skipped test cases in t0060 can be turned on to be tested correctly on Windows. Signed-off-by: Jiang Xin <worldhello.net@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-26path.c: refactor relative_path(), not only strip prefixLibravatar Jiang Xin1-21/+18
Original design of relative_path() is simple, just strip the prefix (*base) from the absolute path (*abs). In most cases, we need a real relative path, such as: ../foo, ../../bar. That's why there is another reimplementation (path_relative()) in quote.c. Borrow some codes from path_relative() in quote.c to refactor relative_path() in path.c, so that it could return real relative path, and user can reuse this function without reimplementing his/her own. The function path_relative() in quote.c will be substituted, and I would use the new relative_path() function when implementing the interactive git-clean later. Different results for relative_path() before and after this refactor: abs path base path relative (original) relative (refactor) ======== ========= =================== =================== /a/b /a/b . ./ /a/b/ /a/b . ./ /a /a/b/ /a ../ / /a/b/ / ../../ /a/c /a/b/ /a/c ../c /x/y /a/b/ /x/y ../../x/y a/b/ a/b/ . ./ a/b/ a/b . ./ a a/b a ../ x/y a/b/ x/y ../../x/y a/c a/b a/c ../c (empty) (null) (empty) ./ (empty) (empty) (empty) ./ (empty) /a/b (empty) ./ (null) (null) (null) ./ (null) (empty) (null) ./ (null) /a/b (segfault) ./ You may notice that return value "." has been changed to "./". It is because: * Function quote_path_relative() in quote.c will show the relative path as "./" if abs(in) and base(prefix) are the same. * Function relative_path() is called only once (in setup.c), and it will be OK for the return value as "./" instead of ".". Signed-off-by: Jiang Xin <worldhello.net@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-26test: add test cases for relative_pathLibravatar Jiang Xin1-0/+37
Add subcommand "relative_path" in test-path-utils, and add test cases in t0060. Johannes tested an earlier version of this patch on Windows, and found that some relative_path tests should be skipped on Windows. This is because the bash on Windows rewrites arguments of regular Windows programs, such as git and the test helpers, if the arguments look like absolute POSIX paths. As a consequence, the actual tests performed are not what the tests scripts expect. The tests that need *not* be skipped are those where the two paths passed to 'test-path-utils relative_path' have the same prefix and the result is expected to be a relative path. This is because the rewriting changes "/a/b" to "D:/Src/MSysGit/a/b", and when both inputs are extended the same way, this just cancels out in the relative path computation. Signed-off-by: Jiang Xin <worldhello.net@gmail.com> Helped-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-29longest_ancestor_length(): require prefix list entries to be normalizedLibravatar Michael Haggerty1-28/+13
Move the responsibility for normalizing prefixes from longest_ancestor_length() to its callers. Use slightly different normalizations at the two callers: In setup_git_directory_gently_1(), use the old normalization, which ignores paths that are not usable. In the next commit we will change this caller to also resolve symlinks in the paths from GIT_CEILING_DIRECTORIES as part of the normalization. In "test-path-utils longest_ancestor_length", use the old normalization, but die() if any paths are unusable. Also change t0060 to only pass normalized paths to the test program (no empty entries or non-absolute paths, strip trailing slashes from the paths, and remove tests that thereby become redundant). The point of this change is to reduce the scope of the ancestor_length tests in t0060 from testing normalization+longest_prefix to testing only mostly longest_prefix. This is necessary because when setup_git_directory_gently_1() starts resolving symlinks as part of its normalization, it will not be reasonable to do the same in the test suite, because that would make the test results depend on the contents of the root directory of the filesystem on which the test is run. HOWEVER: under Windows, bash mangles arguments that look like absolute POSIX paths into DOS paths. So we have to retain the level of normalization done by normalize_path_copy() to convert the bash-mangled DOS paths (which contain backslashes) into paths that use forward slashes. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Jeff King <peff@peff.net>
2012-09-10t0060: split absolute path test in two to exercise some of it on WindowsLibravatar Johannes Sixt1-2/+6
Only the first half of the test works only on POSIX, the second half passes on Windows as well. A later test "real path removes other extra slashes" looks very similar, but it does not make sense to split it in the same way: When two slashes are prepended in front of an absolute DOS-style path on Windows, the meaning of the path is changed (//server/share style), so that the test cannot pass on Windows. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Acked-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-06t0060: verify that real_path() removes extra slashesLibravatar Michael Haggerty1-0/+18
Adjusted for Windows by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-06real_path(): properly handle nonexistent top-level pathsLibravatar Michael Haggerty1-1/+1
The change has two points: 1. Do not strip off a leading slash, because that erroneously turns an absolute path into a relative path. 2. Do not remove slashes from groups of multiple slashes; instead let chdir() handle them. It could be, for example, that it wants to leave leading double-slashes alone. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-06t0060: verify that real_path() works correctly with absolute pathsLibravatar Michael Haggerty1-1/+11
There is currently a bug: if passed an absolute top-level path that doesn't exist (e.g., "/foo") it incorrectly interprets the path as a relative path (e.g., returns "$(pwd)/foo"). So mark the test as failing. These tests are skipped on Windows because test-path-utils operates on a DOS-style absolute path even if a POSIX style absolute path is passed as argument. Adjusted for Windows by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-06real_path(): reject the empty stringLibravatar Michael Haggerty1-1/+1
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-06t0060: verify that real_path() fails if passed the empty stringLibravatar Michael Haggerty1-0/+4
It doesn't, so mark the test as failing. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-06absolute_path(): reject the empty stringLibravatar Michael Haggerty1-1/+1
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-06t0060: verify that absolute_path() fails if passed the empty stringLibravatar Michael Haggerty1-0/+4
It doesn't, so mark the test as failing. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-06t0060: move tests of real_path() from t0000 to hereLibravatar Michael Haggerty1-0/+19
Suggested by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-23t0060: fix whitespace in "wc -c" invocationLibravatar Jeff King1-1/+1
Some platforms like to stick extra whitespace in the output of "wc -c"; using the result without quotes gets the shell to collapse the whitespace. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-22t0060: Fix tests on WindowsLibravatar Johannes Sixt1-33/+83
Since the MSYS bash mangles absolute paths that it passes as command line arguments to non-MSYS progams (such as git or test-path-utils), we have to bend over backwards to squeeze some usefulness out of the existing tests. In particular, a set of path normalization tests is added that test relative paths. Some paths in the ancestor path tests are adjusted to help MSYS bash's path mangling heuristics. Signed-off-by: Johannes Sixt <j6t@kdbg.org>
2009-02-19Introduce the function strip_path_suffix()Libravatar Johannes Schindelin1-0/+4
The function strip_path_suffix() will try to strip a given suffix from a given path. The suffix must start at a directory boundary (i.e. "core" is not a path suffix of "libexec/git-core", but "git-core" is). Arbitrary runs of directory separators ("slashes") are assumed identical. Example: strip_path_suffix("C:\\msysgit/\\libexec\\git-core", "libexec///git-core", &prefix) will set prefix to "C:\\msysgit" and return 0. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Acked-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-07Test and fix normalize_path_copy()Libravatar Johannes Sixt1-16/+17
This changes the test-path-utils utility to invoke normalize_path_copy() instead of normalize_absolute_path() because the latter is about to be removed. The test cases in t0060 are adjusted in two regards: - normalize_path_copy() more often leaves a trailing slash in the result. This has no negative side effects because the new user of this function, longest_ancester_length(), already accounts for this behavior. - The function can fail. The tests uncover a flaw in normalize_path_copy(): If there are sufficiently many '..' path components so that the root is reached, such as in "/d1/s1/../../d2", then the leading slash was lost. This manifested itself that (assuming there is a repository at /tmp/foo) $ git add /d1/../tmp/foo/some-file reported 'pathspec is outside repository'. This is now fixed. Moreover, the test case descriptions of t0060 now include the test data and expected outcome. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-23Add support for GIT_CEILING_DIRECTORIESLibravatar David Reiss1-0/+47
Make git recognize a new environment variable that prevents it from chdir'ing up into specified directories when looking for a GIT_DIR. Useful for avoiding slow network directories. For example, I use git in an environment where homedirs are automounted and "ls /home/nonexistent" takes about 9 seconds. Setting GIT_CEILING_DIRS="/home" allows "git help -a" (for bash completion) and "git symbolic-ref" (for my shell prompt) to run in a reasonable time. Signed-off-by: David Reiss <dreiss@facebook.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-23Implement normalize_absolute_pathLibravatar David Reiss1-0/+40
normalize_absolute_path removes several oddities form absolute paths, giving nice clean paths like "/dir/sub1/sub2". Also add a test case for this utility, based on a new test program (in the style of test-sha1). Signed-off-by: David Reiss <dreiss@facebook.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>