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
Attachment:
signature.asc
Description: PGP signature
