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.

Hi Junio,


On Thu, 9 Feb 2017, Junio C Hamano wrote:

Johannes Schindelin [off-list ref] writes:

quoted

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

How is it that this patch cannot be applied when, and if, that
hypothetical config setting is introduced?

Maybe I am dense here, but I would really like to know why this
preparatory patch must be applied *now*, when there is nothing to prepare
for.

Isn't "Putty is not a command but is also handled as if it is a valid
implementation of SSH" a bug?

If you think it is a bug to handle an ssh command called "putty" as if it
were plink, sure. I do not think there is a valid use case, but hey.

Ciao,
Johannes