From: Paul Drews <paul.drews@intel.com>
Date: Wed, 03 Nov 2010 15:41:06 GMT
Subject: Re: rebase not honoring core.worktree pointing elsewhere
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:

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