Re: git submodule vs GIT_WORK_TREE

[Jens Lehmann <Jens.Lehmann@web.de>]

Am 26.06.2012 21:51, schrieb Junio C Hamano:
> Jens Lehmann <Jens.Lehmann@web.de> 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.