Richard Hartmann <richih.mailinglist@xxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html