On Tue, Nov 2, 2010 at 11:26 PM, Paul Drews <paul.drews@xxxxxxxxx> wrote: > BTW, the impetus for this is a big integrated cross-compilation build system > that has a nasty habit of deleting and re-creating a chroot environment > containing the directory structures including the work tree. ÂIf the ".git" > dir is at the "normal" place "inside" the work tree, it gets deleted along > with all the work I have done. ÂNot good, which is why I want to keep the > ".git" somewhere else that's safe. ÂSolutions to this: > > (preferred) core.worktree pointing into worktree elsewhere, run all git > commands from GIT_DIR. ÂWould be great if rebase worked under these > circumstances. > > (best fallback) no core.worktree, export GIT_DIR pointing elsewhere, run all > git commands from unmarked root of worktree. > > (complex) A complex scenario pushing and pulling stuff between a git repo > inside the worktree and another git clone outside the worktree. > > (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. -- Duy -- 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