Re: rebase not honoring core.worktree pointing elsewhere

From: Paul Drews <paul.drews@intel.com>
Date: Nov 3, 2010, 15:41 UTC
Message-ID: <loom.20101103T162424-483@post.gmane.org>
In-Reply-To: <AANLkTi=T5kHfgNOpOtCDCoq7epEgwUrVayaUCbf35dSU@mail.gmail.com>

Nguyen Thai Ngoc Duy <pclouds <at> gmail.com> writes:

Show 14 quoted lines

> > (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