Nguyen Thai Ngoc Duy <pclouds <at> gmail.com> writes: > > (implementation dependent) Having the ".git" dir inside the worktree be a > > symbolic link to a dir somewhere outside the work tree. ÂKeeps the actual > > ".git" > > contents safe from deletion. ÂWorks so far, but this is Tampering With The > > Implementation in a way that is likely to fail down the road somewhere, > > e.g., if an internal script does cd to the GIT_DIR, then cd relative to > > that to try to get back into somewhere else in the work tree. > > Another one: create a .git file with this line and put it in worktree's > topdir > > gitdir: /path/to/real/git.dir > > See gitrepository-layout.txt. Ooh! That would be my favorite, since it's a documented legal usage. Unfortunately, although the rebase scenario works that way a local "git clone" doesn't work: # git clone /abs/path/to/proj Cloning into proj... fatal: failed to open '/abs/path/to/proj/objects': No such file or directory # git clone /abs/path/to/proj/ Cloning into proj... fatal: failed to open '/abs/path/to/proj//objects': No such file or directory # git --version git version 1.7.3.GIT weird -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html