git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: Jonathan Nieder <jrnieder@gmail.com>,
	Bryan Turner <bturner@atlassian.com>,
	Brandon Williams <bmwill@google.com>,
	Ben Humphreys <behumphreys@atlassian.com>,
	Git Users <git@vger.kernel.org>
Subject: Re: [ANNOUNCE] Git v2.16.0-rc0
Date: Thu, 14 Jun 2018 14:30:19 -0400	[thread overview]
Message-ID: <20180614183018.GA1911@sigill.intra.peff.net> (raw)
In-Reply-To: <xmqqzi009deu.fsf@gitster-ct.c.googlers.com>

On Tue, Jun 12, 2018 at 09:29:13AM -0700, Junio C Hamano wrote:

> Jeff King <peff@peff.net> writes:
> 
> > To be honest, I could easily see an argument that I _should_ be setting
> > GIT_SSH_VARIANT to explain what my wrapper is expecting, even though it
> > happened to work before.
> 
> The way I read that message is that the patch proposed in
> 
>   https://public-inbox.org/git/20180103050730.GA87855@aiede.mtv.corp.google.com
> 
> is "lesser of two evils" in that it is still evil because somebody
> still has to be asked to explicitly set "variant" anyway but the
> changing what 'simple' means in the middle would mean those who did
> not have to set it now have to.  So, you should be setting it, even
> if we adopt the patch, right? ;-)

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.

> My impression is that regression "fix" does not exist---rather, it
> was a proposal (and it may make a better tradeoff than the status
> quo) to help users of older OpenSSH by inconveniencing users of
> different implementations that do -4/6/p differently from OpenSSH.

Right. That fixes the regression for openssh users, at the cost of not
help people on other implementations automatically. But those people
have to set the flag anyway, since the current behavior is "whoops, we
don't know how to support you, set the flag".

To be clear, I've already fixed my setup, and it wasn't that big a deal.
And I doubt all that many people would be affected either way. My use
case here was literally instrumenting the ssh calls of the git client as
part of a regression test suite. How many git test suites could there
possibly be? :)

So I'm OK if we just leave it as-is. It's mostly that I dug into the
thread and was left with the impression that it was an unfinished
leftover that we meant to do.

> In any case, from where I sit, I am still waiting for this offer
> by Jonathan
> 
> > It's good you caught this flaw in the detection.  Would something like
> > the following make sense?  If so, I can resend with a commit message
> > and tests tomorrow or the day after.
> 
> to be followed up ;-)

Yes, that was the part that left the impression. :)

-Peff

  reply	other threads:[~2018-06-14 18:30 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-29  4:30 [ANNOUNCE] Git v2.16.0-rc0 Junio C Hamano
2017-12-29  7:17 ` Kaartic Sivaraam
2017-12-29 17:13 ` Paul Smith
2018-01-04 20:18   ` Thomas Gummerer
2018-01-04 21:35     ` Paul Smith
2018-01-03  3:34 ` Bryan Turner
2018-01-03  5:07   ` Jonathan Nieder
2018-01-03  5:41     ` Bryan Turner
2018-01-03  5:50       ` Jonathan Nieder
2018-01-03 21:15     ` Junio C Hamano
2018-01-03  5:35   ` Jonathan Nieder
2018-06-08  4:50     ` Jeff King
2018-06-12 16:29       ` Junio C Hamano
2018-06-14 18:30         ` Jeff King [this message]
2018-06-14 18:55           ` Jonathan Nieder
2018-06-14 19:39             ` Jeff King
2018-06-15  4:20               ` Jonathan Nieder
2018-06-15  5:13                 ` Jeff King
2018-06-15  7:26                   ` Jeff King
2018-01-04 20:33 ` Johannes Schindelin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180614183018.GA1911@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=behumphreys@atlassian.com \
    --cc=bmwill@google.com \
    --cc=bturner@atlassian.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jrnieder@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).