In strbuf_add_absolute_path, git uses PWD if set when making relative
paths absolute, otherwise it falls back to getcwd(3). Using PWD may not
be a good idea. Here's one case where it confuses git badly:

joey@darkstar:/>sudo ln -s /media/hd/repo hd
joey@darkstar:/>cd /hd/repo
joey@darkstar:/hd/repo>git --git-dir=../../../home/joey/tmp/repo/.git cat-file -t HEAD
fatal: unable to normalize object directory: /hd/repo/../../../home/joey/tmp/repo/.git/objects
joey@darkstar:/hd/repo>ls -d ../../../home/joey/tmp/repo/.git
../../../home/joey/tmp/repo/.git/

In that situation where cd has followed a symlink to a different
depth, there seems to be no way to give git a relative path that works.
Other numbers of ../ also don't work.

What does work is to unset PWD:

joey@darkstar:/hd/repo>PWD= git --git-dir=../../../home/joey/tmp/repo/.git cat-file -t HEAD
commit

So why does git use PWD at all? Some shell code used pwd earlier
(leading to similar bugs like the one fixed in v1.5.1.5), but in
the C code, it was first introduced in commit
1b9a9467f8b9a8da2fe58d10ae16779492aa7737, which speaks of the "user's
view of the current directory", which is what PWD is. The use of PWD in
that commit may be ok.

Then in commit 10c4c881c4d2cb0ece0508e7142e189e68445257, 
the limited use of PWD broadened a lot, seemingly without
intending to look at the "user's view of the current directory"
anymore, due to reusing the code from the earlier commit.

-- 
see shy jo