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

From: Junio C Hamano <gitster@pobox.com>
Date: May 29, 2012, 17:43 UTC
Message-ID: <7vhauy6fy3.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20120528053602.GA11174@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

> I think it depends on the definition of "--local". If it means "when we
> are cloning without a URL, turn on the local optimizations", then yes,
> "file://" should not work. If it means "turn on local optimizations if
> this destination supports it", then it should.

It has meant the former since the day --local was introduced, and the semi-deprecation at 3d5c418 (git-clone: aggressively optimize local clone behaviour., 2007-08-01) didn't change it, either.

> The current behavior is ambiguous as to whether it is the first case, or
> whether it is the second, and it was simply buggy. The history you gave
> argues that the original intent was the former. But to me that is much
> less important than what is useful and least surprising to users.

Changing it would make it even more confusing to people who started using Git before mid 2007, though. That is why I am for deprecating (and eventually removing) "--local".

It is not like we do not have a way to force "local" behaviour. Just give a local pathname and "local" behaviour will kick in; if you do not want "local" behaviour, give network URL or file:// URL. If there were no old scripts, there is no reason to have "--local" in the supported options list of the command.

Having said all that, because the conclusion above is "we need to keep --local for now for old scripts, and its behaviour for sane case should not change", there are some glitches we may want to address for people who try to use "--local" without knowing that it no longer is necessary to use it if you live in modern age. For example:

 $ git clone --local $URL

does not error out, when $URL does not name a repository in the local filesystem. I think that *can* be changed without breaking old scripts. We usually probe to see if $URL is a pathname of a local repository, and then fall back to transports, but we should error out when --local is explicitly asked for, instead of falling back.

Show 5 quoted lines

> There are basically three sane behaviors for "git clone --local
> file://":
>
>   1. --local is silently ignored, because it means "if we are local,
>      turn on optimizations" (though it has a horrible name, in that case)

That is my first preference; "--local" started as an opt-in experiment until it turns out to be useful and became no-op because of 3d5c418, and for the purpose of that experiment, "--local" was perfectly a good name. It is a no-op now.

>   2. it's an error; you should not use --local with a URL

And this is my first preference for a longer time deprecation plan (see above).

>   3. it should use local optimizations (because file:// is local)

Hrm. "file://" has always been a way to say "do not use local optimization". Doesn't it feel simply insane to invent "--local file://" as a way to say "even though the second word on this command line tells you not to use the local optimization, by adding this newly redefined --local option, I am telling you to use the local codepath after all"? Instead, I would prefer to see us just finish the deprecation that started long time ago.