Many tests depend on that symbolic links work. This introduces a check
that sets the prerequisite tag SYMLINKS if the file system supports
symbolic links. Since so many tests have to check for this prerequisite,
we do the check in test-lib.sh, so that we don't need to repeat the test
in many scripts.
To check for 'ln -s' failures, you can use a FAT partition on Linux:
$ mkdosfs -C git-on-fat 1000000
$ sudo mount -o loop,uid=j6t,gid=users,shortname=winnt git-on-fat /mnt
Clone git to /mnt and
$ GIT_SKIP_TESTS='t0001.1[34] t0010 t1301 t403[34] t4129.[47] t5701.7
t7701.3 t9100 t9101.26 t9119 t9124.[67] t9200.10 t9600.6' \
make test
(These additionally skipped tests depend on POSIX permissions that FAT on
Linux does not provide.)
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
In cd_to_toplevel, instead of 'cd $(unset PWD; /bin/pwd)/$path'
use 'cd -P $path'. The "-P" option yields a desirable similarity to
C chdir.
While the "-P" option may be slightly less commonly supported than
/bin/pwd, it is more concise, better tested, and less error prone.
I've already added the 'unset PWD' to fix the /bin/pwd solution on
BSD; there may be more edge cases out there.
This still passes all the same test cases in t5521-pull-symlink.sh and
t2300-cd-to-toplevel.sh, even before updating them to use 'pwd -P'.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
On Mac OS X and possibly BSDs, /bin/pwd reads PWD from the environment if
available and shows the logical path by default rather than the physical
one.
Unset PWD before running /bin/pwd in both cd_to_toplevel and its test.
Still use the external /bin/pwd because in my Bash on Linux, the builtin
pwd prints the same result whether or not PWD is set.
Signed-off-by: Marcel M. Cary <marcel@oak.homeunix.org>
Tested-by: Wincent Colaiuta <win@wincent.com> (on Mac OS X 10.5.5)
Tested-by: Marcel Koeppen <git-dev@marzelpan.de> (on Mac OS X 10.5.6)
Signed-off-by: Junio C Hamano <gitster@pobox.com>
I want directories of my working tree to be linked to from various
paths on my filesystem where third-party components expect them, both
in development and production environments. A build system's install
step could solve this, but I develop scripts and web pages that don't
need to be built. Git's submodule system could solve this, but we
tend to develop, branch, and test those directories all in unison, so
one big repository feels more natural. We prefer to edit and commit
on the symlinked paths, not the canonical ones, and in that setting,
"git pull" fails to find the top-level directory of the repository
while other commands work fine.
"git pull" fails because POSIX shells have a notion of current working
directory that is different from getcwd(). The shell stores this path
in PWD. As a result, "cd ../" can be interpreted differently in a
shell script than chdir("../") in a C program. The shell interprets
"../" by essentially stripping the last textual path component from
PWD, whereas C chdir() follows the ".." link in the current directory
on the filesystem. When PWD is a symlink, these are different
destinations. As a result, Git's C commands find the correct
top-level working tree, and shell scripts do not.
Changes:
* When interpreting a relative upward (../) path in cd_to_toplevel,
prepend the cwd without symlinks, given by /bin/pwd
* Add tests for cd_to_toplevel and "git pull" in a symlinked
directory that failed before this fix, plus contrasting scenarios
that already worked
Signed-off-by: Marcel M. Cary <marcel@oak.homeunix.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
