Re: [PATCH 0/3] clone --local fixes

[Junio C Hamano <gitster@pobox.com>]

Jeff King <peff@peff.net> 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.