On Fri, Mar 25, 2016 at 10:25 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Junio C Hamano <gitster@xxxxxxxxx> 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. Right. Using either "git -C $prefix" or "git --prefix $prefix" would report the $filename only, because both cases assume $prefix was cut using cd_to_toplevel and the user expects $filename only. -- 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