Acceptability of replacing .git internals with symlinks

Git LFS has gotten a couple of bug reports[0][1] about it failing when some of the innards of the `.git` directory are replaced with symlinks. This happens because the Android `repo` tool creates repositories this way; why that is, I don't know.

I know _part_ of the problem for Git LFS is due to the fact that some operations are run under, say, `.git/objects`, and if that's a symlink then the path canonicalization puts the directory elsewhere and the `.git` directory detection fails. I don't know if that's all of the problem, or just part of it.

My inquiry here is whether we consider it acceptable for tools to create symlinks from Git internals in this way and whether this is a thing that should be fixed or not. I haven't tested with alternate Git implementations, such as JGit, Game of Trees, dulwich, libgit2, or others, so I don't know how gracefully they handle this. I will assume for the sake of discussion that the symlinks can be created successfully without elevated permissions and the OS and file system are fully functional in this regard.

I know symlinking the `hooks` directory is common and semi-suppported, but I don't know how we feel about other directories, such as `objects`.

If we _do_ want to support this, then we should probably add some tests for it, and if we don't, then we may want to add advice or diagnostics to discourage this behaviour.

[0] https://github.com/git-lfs/git-lfs/issues/5426 [1] https://github.com/git-lfs/git-lfs/issues/603

"brian m. carlson" <sandals@crustytoothpaste.net> writes:

I do not know how widely it is used, but the git-new-workdir script we ship in contrib/workdir/ does make symlinks from a new directory whose name is ".git" into subdirectories of an existing $GIT_DIR/ to pretend as if the "new-workdir" is a separate Git repository, that happens to share many files and directories like config, refs, objects, etc.

I do not think we ever intended to support ".git" itself being a symbolic link to ".git" directory owned by another repository. We do have ".git" that is a regular file for multiple worktree support, but that is totally different from "just making a symlink for the whole hierarchy".

100% agreed.