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

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 17, 2017, 22:19 UTC
Message-ID: <xmqqd1flcosv.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <20170117214723.p5rni6wwggei366j@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 5 quoted lines

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