Re: [PATCH v6 2/9] connect: only match the host with core.gitProxy

Mike Hommey <mh@glandium.org> writes:

Let's recap.  When you are accessing "git://kernel.org:9418/path"

 - "script1 for kernel.org" does not match, which may be
   counter-intuitive;

 - "script2 for kernel.org:9418" matches and gets used.

Isn't that what the current code does? If so, I suspect that allowing the first one to match may be an improvement with slight backward incompatibility that we agreed that we do not mind.

	Note for those other than Mike: The reason why we do not
	care about the breakage of the backward compatibility is
	because it would only matter when you configured both
	"script1 for kernel.org" and "script2 for kernel.org:9418",
	so that URL can be used to differenciate which proxy script
	to use.  In such a configuration, we used to call script2,
	but "fixing" it would make it call script1.  Given that the
	proxy script takes the port number as its parameter, this
	can be worked around easily by introducing a new script0
	that switches between script1 and script2 based on the port
	number parameter.  IOW, we accept the compatibility breakage
	because adjusting is easy.

We of course need to warn the user if we do this.  That is

 - If the URL we access has :<port>, and we apply <host>-only
   core.gitProxy entry to it, and

 - If the user has core.gitProxy entry for <host>:<port>,

we definitely need to warn so that the user is told that the "easy adjustment" is necessary.

Thinking aloud a bit more, if the user has "script1 for kernel.org" without "script2 for kernel.org:9418", and relied on the fact that having :9418 that is not necessary (as it is the default port) in the URL lets her bypass the proxy script, the user also needs to be told that we have changed the rule of the game and her configuration needs to be updated. So the above condition to warn would need to be loosened, i.e. "if the URL being accessed has :<port>, and if we apply gitProxy specified with only <host>" we need to warn.

A proper transition plan is necessary; if the long term ideal is to use "script1 for kernel.org" for "git://kernel.org:9418/path", we do not want to keep giving this warning forever.

And if we need a transition plan _anyway_, we probably should have a period during which those who have been relying on the fact that "script2 for kernel.org:9418" was a supported way to specify proxy for "git://kernel.org:9418/path" would get a warning but will still use "script2 for kernel.org:9418" as a valid core.gitProxy specification.

So, even if we agree that per-port behaviour is not something we would use if we were building the system without any existing users today, I do not think we want "git now fails with an error" at all. It goes against the approach Git takes to give smooth transtion to users when we must break backward compatibility.