Stefan Beller <sbel...@google.com> writes: > Exactly, sorry for not writing my chain of thoughts down completely. > > To make them reusable, I'd assume we want them to be easy to > understand, and by using a well known way in git it is easier to > understand.
I already said I do not care too deeply either way, but I have to point out that "git -C $prefix" would put extra cognitive burden on those who will be picking it up where you left off. When they start by first literally translating shell to C, "git -C" would mislead them to think if they have to chdir(2) to the directory first, which is not the case at all. "git -C $prefix submodule--helper" in the code after [3/4] is there only because submodule--helper code no longer is told what the caller already knows (i.e. what is the prefix) and is forced to find it out by itself. Contrasting to that, with an explicit --prefix option, the reader would know there is no need to chdir(2) anywhere at that point, but the paths that are held in variables it uses from the surrounding code are not relative to the current working directory when the code is called and $prefix is there to help adjusting it. The reason I do not care too deeply was that I thought people who will be taking over after you are done (well, after all that might include you; plans would change) are clueful, but there is no need for us to make their life more difficult than necessary. -- 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
