All of lore.kernel.org
 help / color / mirror / 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

* 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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.