Re: git submodule vs GIT_WORK_TREE

Jens Lehmann [off-list ref] writes:

Am 26.06.2012 21:51, schrieb Junio C Hamano:
...

quoted

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.

Mangling the email I respond to out of order.

On Wed, Jun 27, 2012 at 12:53 AM, Junio C Hamano [off-list ref] 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.



Richard

[1] https://github.com/RichiH/vcsh