Stefan Beller <sbel...@google.com> writes: >> prefix = setup_git_directory_gently_1(nongit_ok); >> + env_prefix = getenv(GIT_TOPLEVEL_PREFIX_ENVIRONMENT); >> + >> + if (env_prefix) >> + prefix = env_prefix; >> + >> if (prefix) >> setenv(GIT_PREFIX_ENVIRONMENT, prefix, 1); > > so we load that GIT_TOPLEVEL_PREFIX_ENVIRONMENT prefix > first, such that we essentially copy it into GIT_PREFIX_ENVIRONMENT, > such that e.g. aliased commands will know about the superprefix, too.
If the aliased commands or anything else spawned from this process is happy with GIT_PREFIX set to the outside of the current repository, doing this setenv() is OK. If you are in ~/dir1, and your repository is in ~/repos/repo1, and if you somehow had a way to run your "git" inside ~/repos/repo1 without doing any chdir(2), then you are essentially setting ../../dir1/ as GIT_PREFIX for that "git" invocation (this has nothing to do with submodules). But if your "git" is fine with GIT_PREFIX pointing outside the root level of the working tree of the current repository like that, do we even need a separate toplevel prefix environment, I have to wonder? That is, if this "if TOPLEVEL_PREFIX environment is there, set it to local variable prefix and export it as GIT_PREFIX" is expected to work correctly for anything that would inherit that GIT_PREFIX, then we should be able to invoke the "git" that got TOPLEVEL_PREFIX without setting that environment, but instead setting the same value to GIT_PREFIX and we should get the same behaviour, no?
