If we end up in a sub-process where GIT_WORK_TREE is not set
but GIT_DIR is, we assume the current directory is the root
of the working tree. Since future patches will change that
assumption, let's defensively start setting GIT_WORK_TREE

Signed-off-by: Jeff King <p...@peff.net>
I didn't test this very well (in fact, I only noticed the issue after
having written the other two patches, as without it, those ones break
every external command which wants to run in a working tree). I would
not be surprised if there is some code path which sets GIT_DIR but not
this, or if there is some other weird fallout from having GIT_WORK_TREE
set explicitly.

 environment.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/environment.c b/environment.c
index 92c5dff..be2e509 100644
--- a/environment.c
+++ b/environment.c
@@ -194,6 +194,7 @@ void set_git_work_tree(const char *new_work_tree)
        git_work_tree_initialized = 1;
        work_tree = xstrdup(real_path(new_work_tree));
+       setenv(GIT_WORK_TREE_ENVIRONMENT, work_tree, 1);
 const char *get_git_work_tree(void)

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to