Re: [ANNOUNCE] Git v2.16.0-rc0

[Jeff King <peff@peff.net>]

On Thu, Jun 14, 2018 at 11:55:22AM -0700, Jonathan Nieder wrote:

> > No, my wrapper _isn't_ simple. It passes most options to openssh, but
> > just doesn't understand the "-G" probing.  So if the default was
> > openssh-like instead of "simple", then that would work fine without me
> > setting anything, just like it did before.
> >
> > Which I thought was where the discussion ended up, but perhaps I'm
> > misunderstanding.
> 
> Do you mean that it doesn't pass "-G" through, or that when using old
> versions of openssh that doesn't support "-G" the probing fails?

It just doesn't pass "-G" through.

> If the former, then detecting the wrapper as something other than
> "ssh" is intended behavior (though we might want to change what that
> something is, as discussed in the previous thread).  If the latter,
> then this is https://crbug.com/git/7 which I consider to be a bug.

I certainly see the argument that "well, if it doesn't do '-G' then it's
not _really_ openssh". My counter to that is that we don't actually
_care_ about -G (and never did before recently). It's just a proxy for
"do we understand -p", which my script does understand. My wrapper might
eventually break if we depend on new options (like "-o SendEnv"), but
the worst case there is generally no different before or after your
patch: the command barfs.

I say "generally" because of course you can come up with an example
where my script quietly interprets "-o" as something else, but it seems
like most uses there would cause an error.  And anyway, by making me set
GIT_SSH_VARIANT all we've bought is plausible deniability that it's _my_
fault for doing so when my script doesn't handle the new option
gracefully. ;)

But again, I'm just describing what makes sense to me. If you feel
strongly about requiring the variant to be explicitly specified, I can
certainly live with that.

-Peff