Junio C Hamano <gits...@pobox.com> writes: > The way all the subcommand written in C works is > > - The start-up sequence does the repository discovery, which > involves crawling up to the top-level of the working tree, and > compute "prefix", where the end-user was when the command was > invoked; > > - The subcommand implementation is called with this "prefix"; > > - When the subcommand implementation interprets the command line > arguments and option arguments, it prefixes the "prefix" as > needed. If, for example, "git grep -f patterns" is invoked > inside "sub/" subdirectory, when the command line and option > arguments are processed, the process is already at the top level > of the working tree, so it needs to read the patterns from > "sub/patterns" file. "git ls-files 'Makefil*'" invoked inside > "sub/" subdirectory needs to limit the output to those that match > not "Makefile", but "sub/Makefil*". > > The hope of doing an incremental rewrite of the whole thing by > enriching submodule--helper is that the bulk of the code there will > be reusable when the entirety of "git submodule" is rewritten in C, > so they need to take the "prefix" the same way, whether the caller > is calling from "git-submodule.sh" script via submodule--helper, or > the eventual C implementation of "git submodule" is making direct > calls to them. As long as the correct "prefix" is passed to the > routines that are driven via submodule--helper, it does not matter > and I do not care how it is done. > > The current code of "git submodule" whose higher parts are still in > shell would would: > > - The start-up sequence in shell does the cd_to_toplevel and finds > the prefix; > > - "git submodule--helper list --prefix=$prefix $other_args" is > called; as this is called from the top-level of the working tree, > internally its "prefix" is empty, but $other_args must be > interpreted relative to the $prefix passed with --prefix option. > > If we instead call "git -C "$prefix" submodule--helper list $other_args", > then > > - This command first does another chdir(2) back to $prefix; > > - The start-up sequence of "submodule--helper" does the usual > repository discovery again, which involves crawling up to the > top-level of the working tree, and compute "prefix". This > happens to match what -C "$prefix" gave the command. > > Making calls to submodule--helper via "git -C" feels a little bit > roundabout because of this "caller tells to chdir, and then it has > to again chdir back up" only to rediscover the same information.
Just to make sure that the discussion is complete. Another way a script can use the "prefix" information is to use the "prefix" as such. Knowing that the cd_to_toplevel() took you to the root level of the working tree, instead of "git -C $prefix" or "--prefix $prefix", it could do "git $cmd $prefix$filename". One consideration when choosing among the approaches is how the $filename is reported back to the user (e.g. as part of an error message). "git $cmd $prefix$filename" invocation would complain about the full "$prefix$filename" path, but what the user gave it may only be $filename part. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
