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 <peff@xxxxxxxx> --- 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html