kernel/git - git - PowerEL Git System

17553 Commits

6 Branches

36 Tags

131 MiB

Tree: b2f82e05de

Commit Graph

Author	SHA1	Message	Date
Marcel M. Cary	dd6c1360b2	git-sh-setup: Fix scripts whose PWD is a symlink to a work-dir on OS X 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>	16 years ago
Marcel M. Cary	08fc060865	git-sh-setup: Fix scripts whose PWD is a symlink into a git work-dir 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>	16 years ago

Author

SHA1

Message

Date

Marcel M. Cary

dd6c1360b2

git-sh-setup: Fix scripts whose PWD is a symlink to a work-dir on OS X

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>

16 years ago

Marcel M. Cary

08fc060865

git-sh-setup: Fix scripts whose PWD is a symlink into a git work-dir

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>

16 years ago

2 Commits (b2f82e05de2512ae4adb63b669f6c1fe6cba3148)