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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
