Jeff King <peff@xxxxxxxx> writes: > Emeric mentioned that he was confused by the behavior of > > git clone --local file:///path/to/repo > > in that the --local is silently ignored. Looking over the documentation, > it is quite unclear whether it is supposed to do anything or not. According to 23d5335 (git clone: do not issue warning while cloning locally across filesystems, 2007-08-20) and 3d5c418 (git-clone: aggressively optimize local clone behaviour., 2007-08-01), in the very early days we only used the local optimization when the end user explicitly asked for it with the '--local' option. After 3d5c418f, the option has been made a no-op, because the local-ness of the $repository parameter, where the definition of the local-ness is "does 'cd $repository' succeed?", is all that is needed to trigger the codepath. The logic to choose the local optimization has since been "is it a path to a local directory---if so, use the optimizaiton. Otherwise do the usual URL based thing". And that is why we tell people when they want to try cloning without local optimization to add "file://" in front of the path. So your example "file:///" should *not* work even if --local is given, unless you happen to have a directory called "file:" in your current directory and it has path/to/repo subdirectory, which is a git repository. Specifically, the repository at /path/to/repo is not what the command line is naming. I think we probably should stop advertising --local in the documentation and help text. -- 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