{"thread":{"id":"63346","subject":"Acceptability of replacing .git internals with symlinks","startedAt":"2025-04-24T22:32:33Z","lastAt":"2025-04-24T23:05:48Z","messageCount":2,"participants":["brian m. carlson","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"516698","messageId":"aAq7_7pFTToMPX48@tapette.crustytoothpaste.net","threadId":"63346","inReplyTo":null,"subject":"Acceptability of replacing .git internals with symlinks","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2025-04-24T22:32:31Z","receivedAt":"2025-04-24T22:32:33Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"Git LFS has gotten a couple of bug reports[0][1] about it failing when\nsome of the innards of the `.git` directory are replaced with symlinks.\nThis happens because the Android `repo` tool creates repositories this\nway; why that is, I don't know.\n\nI know _part_ of the problem for Git LFS is due to the fact that some\noperations are run under, say, `.git/objects`, and if that's a symlink\nthen the path canonicalization puts the directory elsewhere and the\n`.git` directory detection fails.  I don't know if that's all of the\nproblem, or just part of it.\n\nMy inquiry here is whether we consider it acceptable for tools to create\nsymlinks from Git internals in this way and whether this is a thing that\nshould be fixed or not.  I haven't tested with alternate Git\nimplementations, such as JGit, Game of Trees, dulwich, libgit2, or\nothers, so I don't know how gracefully they handle this.  I will assume\nfor the sake of discussion that the symlinks can be created successfully\nwithout elevated permissions and the OS and file system are fully\nfunctional in this regard.\n\nI know symlinking the `hooks` directory is common and semi-suppported,\nbut I don't know how we feel about other directories, such as `objects`.\n\nIf we _do_ want to support this, then we should probably add some tests\nfor it, and if we don't, then we may want to add advice or diagnostics\nto discourage this behaviour.\n\n[0] https://github.com/git-lfs/git-lfs/issues/5426\n[1] https://github.com/git-lfs/git-lfs/issues/603\n-- \nbrian m. carlson (they/them)\nToronto, Ontario, CA\n"},{"id":"516700","messageId":"xmqqwmb9rwhh.fsf@gitster.g","threadId":"63346","inReplyTo":"aAq7_7pFTToMPX48@tapette.crustytoothpaste.net","subject":"Re: Acceptability of replacing .git internals with symlinks","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2025-04-24T23:05:46Z","receivedAt":"2025-04-24T23:05:48Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"brian m. carlson\" <sandals@crustytoothpaste.net> writes:\n\n> I know symlinking the `hooks` directory is common and semi-suppported,\n> but I don't know how we feel about other directories, such as `objects`.\n\nI do not know how widely it is used, but the git-new-workdir script\nwe ship in contrib/workdir/ does make symlinks from a new directory\nwhose name is \".git\" into subdirectories of an existing $GIT_DIR/ to\npretend as if the \"new-workdir\" is a separate Git repository, that\nhappens to share many files and directories like config, refs,\nobjects, etc.\n\nI do not think we ever intended to support \".git\" itself being a\nsymbolic link to \".git\" directory owned by another repository.  We\ndo have \".git\" that is a regular file for multiple worktree support,\nbut that is totally different from \"just making a symlink for the\nwhole hierarchy\".\n\n> If we _do_ want to support this, then we should probably add some tests\n> for it, and if we don't, then we may want to add advice or diagnostics\n> to discourage this behaviour.\n\n100% agreed.\n"}]}