Re: [PATCH] Export GIT_DIR after setting it

["Björn Steinbrink" <B.Steinbrink@gmx.de>]

On 2008.05.15 10:23:57 -0700, Junio C Hamano wrote:
> "martin f. krafft" <madduck@madduck.net> writes:
> 
> > The only problem I see now is when an external command (or the shell
> > script) can't properly deal with GIT_DIR being set, but then that's
> > a whole different bug.
> 
> One thing that we did not have to worry about when git-sh-setup was
> invented is GIT_WORK_TREE and its cousin core.worktree.  When the user
> uses GIT_DIR _but_ wants to work from a subdirectory of the checked out
> work tree, the user _must_ tell git where the top of the work tree is; in
> other words, setting and exporting only GIT_DIR is a misconfiguration.
> 
> I have a suspicion that "the whole different bug" is what bit you --
> perhaps some places need to also set and export GIT_WORK_TREE as well when
> the do GIT_DIR.

For completeness, here's an actual example of how it breaks:
doener@atjola:g $ git_fake_bare_checkout() {
>                 url="$1"
>                 repo="$2"
>                 worktree="$3"
>                 git clone --no-checkout "$url" "$repo"
>                 cd "$repo"
>                 mkdir -p "$worktree"
>                 git read-tree HEAD
>                 git checkout-index -a --prefix="$worktree" || true
>                 git config core.worktree "$worktree"
>                 mv .git/* .
>                 rmdir .git
>         }
doener@atjola:g $ git_fake_bare_checkout
git://git.madduck.net/etc/git.git git.git ../
Initialized empty Git repository in /home/doener/g/git.git/.git/
Receiving objects: 100% (6/6), done.
remote: Counting objects: 6, done.
remote: Compressing objects: 100% (4/4), done.
remote: Total 6 (delta 0), reused 0 (delta 0)
doener@atjola:git.git (master) $ git fetch
doener@atjola:git.git (master) $ git pull
fatal: Not a git repository
fatal: Not a git repository
fatal: Not a git repository

So the git directory is not called .git but git.git, with core.worktree
set to "../". When "git fetch" is called directly, it correctly finds
that the git dir is "." Same for "git pull", but as GIT_DIR is neither
set in the environment, nor exported by git-pull, the commands that get
executed by git-pull do not find the git dir, because git-pull does
cd_to_toplevel first, and obviously the other commands won't look for
git.git, but just .git.

It kind of feels like a bug that git-pull does not export GIT_DIR there,
but you could probably also argue that it is wrong not to have GIT_DIR
set in the environment when using a non-standard name for the git dir.
Hm?

Björn