1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
|
[[!comment format=mdwn
username="joey"
subject="""comment 5"""
date="2017-11-07T18:21:20Z"
content="""
With somerepo in ~/tmp/repo, and pwd in /hd/repo, which is a symlink from /tmp/hd/repo,
this happens:
chat: git ["--git-dir=../../../home/joey/tmp/repo/.git","--work-tree=../../../home/joey/tmp/repo","--literal-pathspecs","--literal-pathspecs","cat-file","--batch"]
fatal: unable to normalize object directory: /hd/repo/../../../home/joey/tmp/repo/.git/objects
Here it's making git operate on the remote git repo. The relative paths it uses
to it seem legitimate, in that "ls ../.." shows the content of "/tmp" and
"ls ../../.." shows the root directory.
This is a very confusing situation, and different ways of getting the current
directory give different results in this situation. In particular `$PWD`
contains "/hd/repo" while getcwd(3) will return "/tmp/hd/repo". Paths
need to be relative to "/tmp/hd/repo" as that's the *actual* cwd.
It seems that git is looking at `$PWD` to get "/hd/repo" and normalizing
the relative path via that. So there's no possible relative path
that git will accept in this situation. This kind of seems like buggy
behavior on git's part. I've posted about it to the git mailing list.
git-annex could avoid the problem by not using relative paths of course,
but there are reasons including shorter path length (generally)
for its use of relative paths.
git-annex could unset PWD before running git, which forces git to fall
back to using getcwd(3). I've verified that does avoid the problem.
Going to see if this just gets fixed in git before I put in such ugly
and kind of expensive workarounds. (Expensive because, to unset PWD
from the environment, git-annex would have to copy it.)
"""]]
|
