From: Johannes Schindelin Date: Fri, 08 Feb 2008 12:05:08 GMT Subject: Re: [PATCH] allow setting GIT_WORK_TREE to "no work tree" Message-ID: In-Reply-To: <47AC02F5.9080705@viscovery.net> Hi, On Fri, 8 Feb 2008, Johannes Sixt wrote: > Johannes Schindelin schrieb: > > > On Wed, 6 Feb 2008, Johannes Sixt wrote: > > > >> Jeff King schrieb: > >>> In setup_git_directory_gently, we have a special rule that says "if > >>> GIT_DIR is set but GIT_WORK_TREE is not, then use the current > >>> working directory as the work tree." This is the intended behavior > >>> for the user perspective. > >>> > >>> However, setup_git_directory_gently sets GIT_DIR itself, meaning > >>> that further setups (either because we are executing a command via > >>> alias, or in a subprocess) will see the non-existent GIT_WORK_TREE > >>> and assume we fall into the "current working directory is the > >>> working tree" codepath. > >>> > >>> Instead, we now use a special value of GIT_WORK_TREE to indicate > >>> that we have already checked for a worktree and that there isn't > >>> one, setting it when we set GIT_DIR and checking for it in the > >>> special case path. > >>> > >>> The special value is a blank GIT_WORK_TREE; it could be any value, > >>> but this should not conflict with any user values (and as a bonus, > >>> you can now tell git "I don't have a work tree" with "GIT_WORK_TREE= > >>> git", though I suspect the use case for that is limited). > >> > >> Hrm. Unfortunately, on Windows there is no such thing as an empty > >> environment string. setenv(x, "") *removes* the environment variable. > > > > That might be a shortcoming of our implementation of setenv(): > > No, it is not. It's Windows's putenv(), and it's even documented. Yes, that's what I said: our setenv() implementation uses putenv(), which introduces that bug (setenv() is not supposed to unset variables, unsetenv() is). > That said, we probably should modify environ directly in gitsetenv(). Exactly. Ciao, Dscho