rebase not honoring core.worktree pointing elsewhere

> I'm observing an unexpected error from "git rebase" run from the directory
> containing the ".git" directory:
>
> $ git --version
>
> git version 1.7.3.GIT
> (includes up to commit ca2090 from git repository at
> http://www.kernel.org/pub/scm/git/git.git)
>
> $ mkdir wherefilesare
> $ mkdir wheregitis
> $ cd wherefilesare
> $ echo "Here is a line from the original" > myfile.txt
> $ cd ../wheregitis
> $ git init
> $ git config core.worktree /absolute/path/to/wherefilesare/
> $ git add .
> $ git commit
> $ git branch mybranch
> $ git checkout mybranch
> $ vim ../wherefilesare/myfile.txt
> $ git add .
> $ git commit
> $ git checkout master
> $ vim ../wherefilesare/myfile.txt
> $ git add .
> $ git commit
> $ git checkout mybranch
> $ git rebase master
>
> fatal: /usr/libexec/git-core/git-rebase cannot be used without a working tree.
>
> Since I'm in the directory containing ".git" at this point, the ".git" directory
> and the worktree can be unambiguously found.  Other commands besides "git
> rebase" work.  I would expect "git rebase" to work as well.  Is this a bug or an
> unreasonable expectation on my part?

> Hello,
>
> I'm observing an unexpected error from "git rebase" run from the directory
> containing the ".git" directory:
>
> $ git --version
>
> git version 1.7.3.GIT
> (includes up to commit ca2090 from git repository at
> http://www.kernel.org/pub/scm/git/git.git)
>
> $ mkdir wherefilesare
> $ mkdir wheregitis
> $ cd wherefilesare
> $ echo "Here is a line from the original" > myfile.txt
> $ cd ../wheregitis
> $ git init
> $ git config core.worktree /absolute/path/to/wherefilesare/
> $ git add .
> $ git commit
> $ git branch mybranch
> $ git checkout mybranch
> $ vim ../wherefilesare/myfile.txt
> $ git add .
> $ git commit
> $ git checkout master
> $ vim ../wherefilesare/myfile.txt
> $ git add .
> $ git commit
> $ git checkout mybranch
> $ git rebase master
>
> fatal: /usr/libexec/git-core/git-rebase cannot be used without a working tree.
>
> Since I'm in the directory containing ".git" at this point, the ".git" directory
> and the worktree can be unambiguously found.  Other commands besides "git
> rebase" work.  I would expect "git rebase" to work as well.  Is this a bug or an
> unreasonable expectation on my part?

> First of all, core.worktree should not matter because GIT_DIR has not
> been set (No don't trust core.worktree documentation, it's equivalent
> to --work-tree in "man git"). You need to set GIT_DIR (or --git-dir).
> That's a bug I'm working on.
> 
> Then, yes, rebase should be updated to use worktree even if it's
> outside cwd. I'm not sure how to do it properly in git-rebase.sh
> though.  The requirement "require_work_tree" can be loosen a bit.

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

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

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

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

> Paul Drews wrote:
>> Nguyen Thai Ngoc Duy <pclouds <at> gmail.com> writes:
>
>>> 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.
>
> By the way, .git symlinks have been historically supported and are not
> likely to break, either.  Maybe gitrepository-layout should grow to
> include a section on the repository search.
>
>> 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
>
> enter_repo() never learned .git file support, though I see no reason it should
> be hard to add.