Johannes Schindelin <johannes.schinde...@gmx.de> writes: >> > (And that would have to be handled at a different point, as I had >> > pointed out, so that suggested preparation would most likely not help >> > at all.) >> >> I did not think "that would have to be handled at a different point" >> is correct at all, if by "a point" you meant "a location in the >> code" [*1*]. > > Yes, I mean the location in the code. > > But since you keep insisting that you are right and I am wrong,...
There is no "insisting". Didn't we just see how wrong you were about "different point"? An extended syntax of override would be handled in the new helper to handle override, the same point in the code as other overrides are handled. > ... and even > go so far as calling your patch reverting my refactoring a hot-fix, why > don't you just go ahead and merge the result over my objections? At this point, you are simply being silly. Isn't "Putty is not a command but is also handled as if it is a valid implementation of SSH" a bug? Isn't making the code not to be confused like so a fix? A different approach to fix the issue would be to declare that the command names and overrides are not in separate namespaces. If you prefer to go that route, the documentation can use an update to make it not mention "putty" as a valid override (the users have to spell "plink"), mention "plink.exe" is also accepted, etc. and make it clear that the override environment and configuration variables are the way to tell Git: "The ssh implementation I have behaves the same way as this well-known implementation, so treat it as such without actually looking at the path to the command in the ssh.command string". That may limit the freedom for future enhancement of overrides, but is an acceptable short-cut. After all, the overrides are merely an escape hatch and we expect them to be used only rarely.
