Re: What's cooking in git.git (Feb 2017, #02; Mon, 6)

Johannes Schindelin [off-list ref] writes:

quoted

quoted

(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.