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
explicitly.
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)
--
1.8.2.13.g0f18d3c
--
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
