Stefan Beller <sbel...@google.com> writes: > Which is why I'd strongly consider having it only in the repository > object as that is the largest-scoped thing we'd want. e.g. submodules > should care about environment variables differently: > > GIT_WORK_TREE=~/mysuperproject git checkout \ > --recurse-submodules master > > So with such a command in mind, the environment variable would > only apply to the superproject and the nested submodules should > ignore the env, but compute their paths off the superproject, i.e. > the superproject repository, not its object store?
In the longer term endgame state, what is in the repository object cannot just be a simple "do we honor environment variable" bit anymore. It will be more like "we may (or may not) look at environment when we create a repository object", i.e. a bit passed to repo_init() constructor, and from then on, the repository object knows where the object store and its alternates are, where the top of the working tree is, where the repository (i.e. the directory that has "refs/" in it) is, what "worktree" of the repository we are talking about by itself. There is no need for a bit "do we or do we not look at environment?" that needs to be consulted at runtime, which is quite a round-about thing. In your example, the repository object that represents the superproject will pay attention to GIT_WORK_TREE environment when it is consturcted, and repository objects dynamically constructed while the command "recurse-submodules" through them will be constructed with their "where is the top of my working tree?" set appropriately. They won't be storing "when figuring out where my working tree is, do not pay attention to GIT_WORK_TREE environment variable" bit.
