Re: Problems with new location of submodule's GIT_DIR

From: Phil Hord <phil.hord@gmail.com>
Date: Aug 17, 2012, 17:38 UTC
Message-ID: <CABURp0q84skieqmdd5qSBrdXFTOjNm5asQgVrB42UttrEOEpDw@mail.gmail.com>
In-Reply-To: <502E73E4.9080601@web.de>

On Fri, Aug 17, 2012 at 12:40 PM, Jens Lehmann <Jens.Lehmann@web.de> wrote:

Show 16 quoted lines

> Am 17.08.2012 17:28, schrieb Daniel Milde:
>> Hi all,
>> I have encountered some difficulties with the new location of the
>> metainformation directory (GIT_DIR) of submodules.
>>
>> The change of location happened in 1.7.8:
>>
>>  * When populating a new submodule directory with "git submodule init",
>>    the $GIT_DIR metainformation directory for submodules is created
>> inside
>>    $GIT_DIR/modules/<name>/ directory of the superproject and referenced
>>    via the gitfile mechanism. This is to make it possible to switch
>>    between commits in the superproject that has and does not have the
>>    submodule in the tree without re-cloning.
>>
>> Which problems it causes:

Show 7 quoted lines

>> 3) Submodules became dependent on superproject. This is quite bad if you
>> are using submodules a lot (e.g. versioning the whole working space),
>> because you cannot move or copy them out of the superproject now.
>
> Okay, that use case is new to me. What is the intention when you move a
> submodule out of the work tree? Couldn't you just as easily clone the
> upstream repo again at the new place?

Not all git projects have upstreams.  Maybe this is a local project only.

In any case, cloning the upstream anew does not preserve local history.

Maybe the future 'git submodule mv' can be smart about moving a submodule to a new location outside of a superproject. Maybe it can do so explicitly with the --export switch.

Phil