On Wed, Jan 18, 2017 at 01:34:28PM +0100, Johannes Schindelin wrote: > > > 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