Mike Hommey <mh@xxxxxxxxxxxx> writes: > Currently, core.gitProxy doesn't actually match purely on domain names > as documented: it also matches ports. > > So a core.gitProxy value like "script for kernel.org" doesn't make the > script called for an url like git://kernel.org:port/path, while it is > called for git://kernel.org/path. 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. > This per-port behavior seems like an oversight rather than a deliberate > choice, so, make git://kernel.org:port/path call the gitProxy script in > the case described above. 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. > However, if people have been relying on this behavior, git now fails > with an error message inviting for a configuration change. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html