Am 26.06.2012 21:51, schrieb Junio C Hamano: > Jens Lehmann <Jens.Lehmann@xxxxxx> writes: > >> Am 26.06.2012 18:07, schrieb Junio C Hamano: >> ... >>> When the user exports GIT_WORK_TREE to tell git that the root of the >>> working tree the user wants to work on resides there (which is >>> needed when the user exports GIT_DIR to tell git that the user wants >>> to work on that repository), that wish obviously applies only to >>> that repository. If git decides to visit the working tree of a >>> different repository (e.g. a checkout of a submodule bound to the >>> project GIT_WORK_TREE points at), even if it is done in response to >>> the user action (e.g. like passing "--recurse-submodules" option), >>> it should adjust GIT_WORK_TREE and GIT_DIR to be appropriate for >>> operations in the submodule repository while doing so. If the more >>> recent "recursive" behaviour forgets to do so, it simply is a bug. >> >> I'm not sure what you mean by "appropriate for operations in the >> submodule repository". Should the submodule work tree be searched >> for under $GIT_WORK_TREE of the superproject or under $(pwd)? > > I think either > > (1) unset GIT_WORK_TREE/GIT_DIR if the process chdirs to > $GIT_WORK_TREE/submodule and $GIT_WORK_TREE/submodule/.git is > the controlling reopsitory of that submodule working tree, or > > (2) set GIT_WORK_TREE/GIT_DIR to point at the working tree and > repository of the submodule. > > would be appropriate. Agreed. >> As far as I can see all submodule code consistently clears all >> environment variables used by git before descending into a >> submodule (at least since February 2010 and 5ce9086dd). Maybe we >> should change that so it sets the GIT_WORK_TREE environment to >> "$GIT_WORK_TREE/submodule" to be consistent? > > 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. -- 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