From 4070b13bc1e5dd3ad973f3283c115e890f4fb921 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Tue, 7 Nov 2017 15:33:55 -0400 Subject: analysis Should add a link to my git ML post when it gets through. This commit was sponsored by Bruno BEAUFILS on Patreon. --- ...ent_5_cb5332119c54764b4ef1e000b3767b0e._comment | 35 ++++++++++++++++++++++ 1 file changed, 35 insertions(+) create mode 100644 doc/bugs/fatal__58___unable_to_normalize_object_directory/comment_5_cb5332119c54764b4ef1e000b3767b0e._comment (limited to 'doc/bugs') diff --git a/doc/bugs/fatal__58___unable_to_normalize_object_directory/comment_5_cb5332119c54764b4ef1e000b3767b0e._comment b/doc/bugs/fatal__58___unable_to_normalize_object_directory/comment_5_cb5332119c54764b4ef1e000b3767b0e._comment new file mode 100644 index 000000000..f6c6e5f4f --- /dev/null +++ b/doc/bugs/fatal__58___unable_to_normalize_object_directory/comment_5_cb5332119c54764b4ef1e000b3767b0e._comment @@ -0,0 +1,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.) +"""]] -- cgit v1.2.3