git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Michael J Gruber <git@drmicha.warpmail.net>
To: Junio C Hamano <gitster@pobox.com>, Jeff King <peff@peff.net>
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>, git@vger.kernel.org
Subject: Re: [PATCH] gpg-interface: reflect stderr to stderr
Date: Mon, 12 Sep 2016 15:39:55 +0200	[thread overview]
Message-ID: <3b2f13c5-c315-7156-5126-8f469956d645@drmicha.warpmail.net> (raw)
In-Reply-To: <xmqqzinidqfi.fsf@gitster.mtv.corp.google.com>

Junio C Hamano venit, vidit, dixit 08.09.2016 23:36:
> Jeff King <peff@peff.net> writes:
> 
>>> Even though this patch is fixing only one of the two issues, I am
>>> tempted to say that we should queue it for now, as it does so
>>> without breaking a bigger gain made by the original, i.e. we learn
>>> the status of verification in a way the authors of GPG wants us to,
>>> while somebody figuires out what the best way is to show the prompt
>>> to the console on Windows.
>>
>> That's OK by me, but I don't know if we can put off the "best way to
>> show the prompt" fix. It seems like a pretty serious regression for
>> people on Windows.
> 
> Yes, I am not saying that it is OK to keep Windows users broken.
> 
> As I understand what Dscho said correctly, his users are covered by
> a reversion of the "read the GPG status correctly" patch, i.e. with
> a different trade-off between the correctness of GPG status vs
> usability of the prompt, he will ship with Git for Windows, and that
> stop-gap measure will last only until developers who can do Windows
> (which excludes you, me, and Michael it seems) comes up with a
> solution that satisfies both.

Unfortunately "I can't do Windows". Also, I'm not sure "I can do pipes",
but it's really the ifdeffing that keeps me from even trying: Nothing is
gained for Windows users if I extend the Linux code to use an extra file
handle for status-fd - which would be the clean and correct solution,
but which would need to be implemented twice.

> I consider that an approach that is perfectly fine.

As a side note, I'm wondering why MSYS-gpg version 1 is bundled with
non-MSYS-git. It's an honest question - there must be good reasons for
that, and git should work with gpg 1, 2 (maybe) and 2.1, of course. I'm
just trying to understand the situation, and the question goes both ways:

- some Windows user(s) in the Github issue apparantly had wrong
assumptions about which gpg they're using (via git) - why bundle it at all?

- If bundling it to get a known working setup, why not gpg 2(.1) which
runs gpg-agent automatically, giving a more Windows-like experience for
the passphrase-prompt?

On Fedora, with some things still requiring gpg 1, gpg 2.1 installed in
parallel, things can become confusing quickly because  of the 1-time
1-way migration of the secret key store. It's probably the same on
Windows with those two gpg's used in parallel (and probably answers my
second question).

Michael

  reply	other threads:[~2016-09-12 13:40 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-06  8:01 [PATCH] Unbreak interactive GPG prompt upon signing Johannes Schindelin
2016-09-06 12:32 ` Michael J Gruber
2016-09-06 13:13   ` [PATCH] gpg-interface: reflect stderr to stderr Michael J Gruber
2016-09-06 16:30     ` Johannes Schindelin
2016-09-06 16:42       ` Johannes Schindelin
2016-09-06 16:43         ` Johannes Schindelin
2016-09-07  8:27           ` Michael J Gruber
2016-09-07  8:39             ` Jeff King
2016-09-07  9:32               ` Michael J Gruber
2016-09-08 18:20               ` Junio C Hamano
2016-09-08 20:03                 ` Jeff King
2016-09-08 21:36                   ` Junio C Hamano
2016-09-12 13:39                     ` Michael J Gruber [this message]
2018-10-02 13:02                       ` Johannes Schindelin
2016-09-09  7:28                 ` Johannes Schindelin
2016-09-06 16:39   ` [PATCH] Unbreak interactive GPG prompt upon signing 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=3b2f13c5-c315-7156-5126-8f469956d645@drmicha.warpmail.net \
    --to=git@drmicha.warpmail.net \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=peff@peff.net \
    /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).