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

From: Junio C Hamano <gitster@pobox.com>
Date: May 27, 2012, 06:32 UTC
Message-ID: <7vsjemp20j.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20120526034226.GA14287@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 6 quoted lines

> 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.