Re: git submodule vs GIT_WORK_TREE

[Junio C Hamano <gitster@pobox.com>]

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

> First of all, thanks for your detailed analysis; it cleared things up
> for me quite a bit.
>
> I am not sure if this would work in all cases, but let's assume there
> is a new GIT_WORK_ROOT which will always point to the top level of a
> given repository (it would stay the same for submodules, as well).

I do not think such a variable is necessary, and I do not think it
helps anything either.

As a submodule is an independent project and does not care if it is
embedded inside another project (i.e. superproject), when you are
working in $HOME/a/b repository (going back to the example in the
previous message), whether using b/.git or GIT_WORK_TREE=$HOME/a/b
as the clue to mark the root of the working tree of the project you
are working in, there is no reason for Git to figure out that there
is a containing superproject at $HOME/a, let alone that its
controlling repository is at $HOME/a/.git (or somewhere else).

The problem is going the other way around.

When you are working in the superproject, i.e. $HOME/a, there is a
need to know when you cross the project boundary at $HOME/a/b (and
if you know $HOME/a/b is the project boundary, that automatically
means $HOME/a/b is the root level of the working tree of the other
project, so Git with "--recursive" option _ought_ to be aboe to
export GIT_WORK_TREE one it goes into the working tree of the
submodule without anything else).

But even if you can know where the project boundary is in the
working tree space, that does not automatically mean you will be
able to know where the controlling repository for $HOME/a/b is, if
you moved it away from its natural location $HOME/a/b/.git to
somewhere else.  There needs to be a way to tell Git about that.

And an obvious way to do so is to have $HOME/a/b/.git; it can be a
real repository, which would make things simple, but it does not
have to be.  It can be the "gitfile:" thing that points at somewhere
else.  In recent versions of git, submodule working trees have this
as a "gitfile:" that points at $GIT_DIR/modules/$name of the
superproject, so that the working tree can be removed when checking
out an old version of superproject before such a submodule was added
to the project without losing the controlling repository.

So I do not see a need for either WORK_ROOT or DIR_ROOT at all.

The superproject (e.g. $HOME/a) may have its controlling repository
elsewhere (you are naming its location with $GIT_DIR when you name
the working tree of it with $GIT_WORK_TREE), and that controlling
repository can have modules/b directory that is the controlling
repository for the submodule whose working tree is at $HOME/a/b;
there is no need for anything else as long as there is enough clue
for the system to find out that $HOME/a/b is the project boundary.