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

From: Jeff King <peff@peff.net>
Date: May 30, 2012, 11:03 UTC
Message-ID: <20120530110305.GA13445@sigill.intra.peff.net>
In-Reply-To: <7vhauy6fy3.fsf@alter.siamese.dyndns.org>

On Tue, May 29, 2012 at 10:43:32AM -0700, Junio C Hamano wrote:

Show 10 quoted lines

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

Right, but my argument was that since nobody probably ever cared about the distinction, it is more important to do the least surprising thing.

Show 8 quoted lines

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

Yes, it would technically be a regression. But I highly doubt that somebody is relying on the fact that "--local" with file:// is a silent no-op. And other than that, the behavior remains the same (note that my patch explicitly did not try to turn on --local when it sees file://).

Anyway, I do not really care about this part of the series. It was not "this is a needed feature" but rather "this is less surprising and easy to do, so why not?". We can drop it and replace it with a documentation update.

I would still like to keep the --no-local patch, for two reasons:

  1. The fact that using file:// overrides the local optimizations is
     somewhat non-obvious if you do not already know that it is the
     case.

  2. File URLs require absolute paths[1]. You can't do the equivalent of
     "git clone --no-local foo.git" without resorting to $PWD.

So here's an updated series (I see you took the test cleanups already).

  [1/2]: docs/clone: mention that --local may be ignored
  [2/2]: clone: allow --no-local to turn off local optimizations

I didn't bother with deprecation or erroring out on URLs. So far we have had exactly one report on this, and I think the improved documentation would have solved this particular case.

-Peff