Re: git submodule vs GIT_WORK_TREE

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 29, 2012, 20:03 UTC
Message-ID: <7v8vf551iu.fsf@alter.siamese.dyndns.org>
In-Reply-To: <CAD77+gSyhR+4vdv3dEVSuEvyt7mT9ojT-F2BrwTL4FsXpNFeHA@mail.gmail.com>

Richard Hartmann <richih.mailinglist@gmail.com> writes:

Show 27 quoted lines

> Mangling the email I respond to out of order.
>
> On Wed, Jun 27, 2012 at 12:53 AM, Junio C Hamano <gitster@pobox.com> wrote:
>
>> 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.
>
> This is exactly the point. For vcsh[1] to work, I need to set it up like this:
>
>     richih@titanium  ~ % vcsh enter zsh
>     richih@titanium [zsh] [2] (git)-[master] ~ % echo $GIT_WORK_TREE
>     /home/richih
>     richih@titanium [zsh] [2] (git)-[master] ~ % echo $GIT_DIR
>     /home/richih/.config/vcsh/repo.d/zsh.git
>     richih@titanium [zsh] [2] (git)-[master] ~ %
>
>
>> 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,
>
> I fear this would make vcsh unable to support submodules, ever.

Then think of a workable alternative. As it stands, I would have to say that what vcsh tries to do with git is broken with respect to submodules.