Re: GIT_DIR in aliases [Re: Spurious GIT_DIR set when in a worktree [was Re: Nested submodule status bug]

[Damien Robert <damien.olivier.robert@gmail.com>]

From Jeff King, Fri 28 Feb 2020 at 14:02:18 (-0500) :
> > Furthermore there is a question of consistency. GIT_DIR will not always be set
> > before running a shell alias. Looking at `setup_discovered_git_dir`, it will
> > be set if we are in a bare dir, or core.worktree / WORK_TREE is set, or if
> > we have a gitfile.

> We were discussing the same issue recently with regards to hooks. See:
>   https://lore.kernel.org/git/20200130102933.GE840531@coredump.intra.peff.net/
> and the responses. I think we could do better, but at the cost of
> breaking a relatively obscure git-clone feature.

Yes I found this discussion afterwards. This is related but a bit
different, the problem you discuss is that GIT_WORK_TREE is not always set
even when GIT_DIR is. The problem I have is that GIT_DIR is not always set; it
depends on the phase of the moon (are we in a worktree? ...), which makes
things that forget to unset it half broken and hard to debug.

I would argue that for scripts and hooks we should always set both. This is
easy to do (at least for scripts, I haven't looked at hooks) without
touching at setup_discovered_git_dir, so not affecting git clone.

In fact I would even argue that in setup_discovered_git_dir we should
always set both, and fix the breakages that appear, like the one you
mention for git clone. For instance I wonder if the recent report about
'git gui' setting GIT_DIR is not due to this.

> Note there are other variables you might want to unset, too, if you're
> switching repositories. Doing:
>   unset $(git rev-parse --local-env-vars)
> would cover the full list.

Thanks for the hint; I had forgotten about local-env-vars.