analysis

Should add a link to my git ML post when it gets through.

This commit was sponsored by Bruno BEAUFILS on Patreon.

1 files changed, 35 insertions, 0 deletions

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.)
+"""]]