Jens Lehmann <Jens.Lehmann@xxxxxx> writes: > Am 26.06.2012 21:51, schrieb Junio C Hamano: > ... >> If the user has to use GIT_WORK_TREE to mark the root level of the >> superproject working tree as such, it is very likely that the >> controlling repository of the superproject does not live in the >> $GIT_WORK_TREE/.git directory (in other words, $GIT_DIR points at >> somewhere else). Exporting GIT_WORK_TREE/submodule as the new value >> of GIT_WORK_TREE is sensible, but I do not see a reasonable way to >> deduce the value of GIT_DIR for the submodule in such a case. The >> controlling repository of the superproject is located somewhere >> random; there is no reason to assume the repository for the >> submodule is somewhere at fixed relation to it. >> >> Does it mean the short answer to Richard's situation is "Don't do >> it"? I am not sure, but it is starting to sound like it. > > Not at all, I was just trying to reach consensus on what the user > can reasonably expect when setting GIT_WORK_TREE in the presence of > submodules. I will look into it to see how we can handle the cases > where GIT_WORK_TREE and/or GIT_DIR are set. Thanks, then I'll let you look into it. I do not see how you could determine GIT_DIR for the submodule sensibly if the superproject's working tree does not have its GIT_DIR as ".git" at the top-level, though. Declaring that a checked out submodule _must_ have its controlling repository as ".git" at its root level, i.e. it should be accessible without using GIT_WORK_TREE/GIT_DIR at all just like a normal Git repository is, would be a clean way to avoid the issue altogether and it still will allow the top-level superproject to be structured in a funny way to require GIT_WORK_TREE/GIT_DIR to access it, but I am not sure if that is too restrictive for people who for some unknown reason want to use these environment variables to create repositories with a strange layout. -- 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