Stefan Beller <sbeller@xxxxxxxxxx> writes: > In the rewrite from shell to C (ee8838d157761, 2015-09-08, submodule: > rewrite `module_clone` shell function in C), we never made use of the > prefix. Probably it sneaked in as module_list which was converted in the > same series had the prefix as well. > > Signed-off-by: Stefan Beller <sbeller@xxxxxxxxxx> > --- Hmph. This helper is called from the root level of the superproject's working tree (after cd_to_toplevel is done), and has options like --url. If the user named --url with a relative pathname to a local repository directory (or a bundle file), shouldn't it be adjusted, and wouldn't prefix the only clue what that given path is relative to? Same for --reference repository's path. I am not sure removing "--prefix=$wt_prefix" without doing "git -C $wt_prefix" on the calling side is the right thing to do. Even though the options list used by this function does not seem to use OPTION_FILENAME, parse-options API takes prefix exactly because relative pathnames need to be adjusted, and it smells like that the breakage brought in by this change is merely hidden by existing bugs in the code that does not use prefix to adjust relative paths. -- 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