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

Jeff King [off-list ref] writes:

quoted

Let's fix this by telling Git that a remote is not configured unless any
fetch/push URL or refspec is configured explicitly.

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?

"Not configured unless any URL or refspec is configured" means that
if URL is there, even if there is no refspec, then it is a remote
definition, right?  

But I think "what does it mean to define a remote" is a question
that you are asking, and that is not necessary to answer within the
scope of this topic.

I do agree that honoring .prune is nonsense unless refspecs are
defined, but the question "does it make sense to allow prune?"  is
different from "is it configured?".  Your "you can set .proxy and
other useful things, it is just .prune does not make sense" is a
quite appropriate statement to illustrate the difference.

Perhaps instead of adding "is it configured?" flag that is too
broadly named and has too narrow meaning, would it make more sense
to introduce "int can_prune(struct remote *remote)" that looks at
the remote refspecs?

Hi Junio,

On Tue, 17 Jan 2017, Junio C Hamano wrote:

Perhaps instead of adding "is it configured?" flag that is too
broadly named and has too narrow meaning, would it make more sense
to introduce "int can_prune(struct remote *remote)" that looks at
the remote refspecs?

That ("can we prune?") is not the question we need to ask when determining
whether we can rename a remote to a new name.

Ciao,
Johannes