Re: [PATCH 2/2] Be more careful when determining whether a remote was configured

From: Jeff King <peff@peff.net>
Date: Jan 18, 2017, 12:54 UTC
Message-ID: <20170118125422.gi3ppqiqhyykk7iy@sigill.intra.peff.net>
In-Reply-To: <alpine.DEB.2.20.1701181334040.3469@virtualbox>

On Wed, Jan 18, 2017 at 01:34:28PM +0100, Johannes Schindelin wrote:

Show 11 quoted lines

> > > Let's fix this by telling Git that a remote is not configured unless any
> > > fetch/push URL or refspect is configured explicitly.
> > 
> > Hmm. Old versions of GitHub for Windows used to set fetch refspecs in
> > the system gitconfig, for a similar purpose to what you want to do with
> > remote.origin.prune.
> > 
> > I notice here that setting a refspec _does_ define a remote. Is there a
> > reason you drew the line there, and not at, say, whether it has a URL?
> 
> I want to err on the side of caution. That's why.

I guess I just don't see why changing the behavior with respect to "prune" or "proxy" is any less conservative than changing the one for "refspec". Both can make some real-world cases work, and both can cause breakage in some possible real-world cases. If we are going to change anything, it seems like we should at least aim for a simple and consistent rule (since users have to know which keys can be put in ~/.gitconfig and which cannot).

I can think of one alternative approach that might be easier for users to understand, and that we already use elsewhere (e.g., with "http.*" config): have a set of "default" remote keys (e.g., just "remote.key") that git falls back to when the remote.*.key isn't set. Then your use case becomes something like:

  [remote]
  prune = true

That's not _exactly_ the same, as it applies to all remotes, not just "origin" (other remotes can override it, but would need to do so explicitly). But I have a suspicion that may actually be what users want.

-Peff