Christian Couder <christian.couder@xxxxxxxxx> writes: > While at it, let's warn and reject the remote, in the 'KnownUrl' case, > when no URL or an empty URL is advertised by the server, or when an > empty URL is configured on the client for a remote name advertised by > the server and configured on the client. This is on par with a warning > already emitted when URLs are different in the same case. That explanation makes it unclear why we need a new one. If the configured and davertised are both empty and the same, according to that "warning already emitted", that is not a warning-worthy event, is it? > Let's also warn if the remote is rejected because name and url are the > same, as it could mean the url has not been configured. Are we rejecting a remote _because_ r->name is used? I thought the code did something quite different. We reject because the url does not match, and then after that give an extra warning if remote nick was used as a fallback URL. Even if URL is configured as 'orogin' for a remote with nick 'origin', the code would have rejected the remote with the same logic in the same code path, wouldn't it? It is a bit confusiong to call such a situation "rejected because name and URL are the same". In any case, why do we want to keep these unconfigured remotes in the list of candidate lop-remotes in the first place, and why do we want to treat empty URLs as being so special, more special than say a randomly misspelt URL? I think I asked these questions on the previous round and I do not think I saw them addressed at all in this round. Thanks.
