summaryrefslogtreecommitdiff
path: root/t/t3004-ls-files-basic.sh
AgeCommit message (Collapse)AuthorFilesLines
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-04t3004: add test for ls-files on symlinks via absolute pathsLibravatar Junio C Hamano1-0/+17
When symlinks in the working tree are manipulated using the absolute path, git dereferences them, and tries to manipulate the link target instead. 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. This is a regression introduced by 18e051a: setup: translate symlinks in filename when using absolute paths (which did not take symlinks inside the work tree into consideration). Add a known-breakage test using the ls-files function, checking both if the symlink leads to a target in the same directory, and a target in the above directory. Signed-off-by: Martin Erik Werner <martinerikwerner@gmail.com> Tested-by: Martin Erik Werner <martinerikwerner@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-27Fix tests under GETTEXT_POISON on parseoptLibravatar Jiang Xin1-2/+2
Use the i18n-specific test functions in test scripts for parseopt tests. This issue was was introduced in v1.7.10.1-488-g54e6d: 54e6d i18n: parseopt: lookup help and argument translations when showing usage and been broken under GETTEXT_POISON=YesPlease since. Signed-off-by: Jiang Xin <worldhello.net@gmail.com> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-10-22ls-files -h: show usage even with corrupt indexLibravatar Nguyễn Thái Ngọc Duy1-0/+39
Part of a campaign to avoid git <command> -h being distracted by access to the repository. A caller hoping to use "git ls-files" with an alternate index as part of a repair operation may well use "git ls-files -h" to show usage while planning it out. [jn: with rewritten log message and tests] Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>