Re: [PATCH] gpg-interface: reflect stderr to stderr

From: Michael J Gruber <git@drmicha.warpmail.net>
Date: Sep 12, 2016, 13:39 UTC
Message-ID: <3b2f13c5-c315-7156-5126-8f469956d645@drmicha.warpmail.net>
In-Reply-To: <xmqqzinidqfi.fsf@gitster.mtv.corp.google.com>

Junio C Hamano venit, vidit, dixit 08.09.2016 23:36:

Show 22 quoted lines

> 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