On 03/17, Junio C Hamano wrote: > Stefan Beller <sbeller@xxxxxxxxxx> 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? > Very true, potentially we could just use GIT_PREFIX instead of introducing a brand new env var (which is essentially just the same thing). I was being cautious with this patch since git didn't currently read GIT_PREFIX. I was hoping other with more knowledge in this area would voice their opinions and lead me in the right direction ;) -- Brandon Williams