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>
test_i18ngrep "[Uu]sage: git ls-files " broken/usage
'
+test_expect_failure SYMLINKS 'ls-files with absolute paths to symlinks' '
+ mkdir subs &&
+ ln -s nosuch link &&
+ ln -s ../nosuch subs/link &&
+ git add link subs/link &&
+ git ls-files -s link subs/link >expect &&
+ git ls-files -s "$(pwd)/link" "$(pwd)/subs/link" >actual &&
+ test_cmp expect actual &&
+
+ (
+ cd subs &&
+ git ls-files -s link >../expect &&
+ git ls-files -s "$(pwd)/link" >../actual
+ ) &&
+ test_cmp expect actual
+'
+
test_done