Hi Michael,
[blast from the past]
On Mon, 12 Sep 2016, Michael J Gruber wrote:
> As a side note, I'm wondering why MSYS-gpg version 1 is bundled with
> non-MSYS-git.
Those are two questions:
- an MSYS version of GPG is bundled because it was the stable one
available at the time when I had to
Junio C Hamano venit, vidit, dixit 08.09.2016 23:36:
> Jeff King 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
Hi Junio,
On Thu, 8 Sep 2016, Junio C Hamano wrote:
> Jeff King writes:
>
> > On Wed, Sep 07, 2016 at 10:27:34AM +0200, Michael J Gruber wrote:
> >
> >> Now, I can't reproduce C on Linux[*], so there is more involved. It
> >> could be that my patch just exposes a problem in our start_command()
Jeff King 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,
>> w
On Thu, Sep 08, 2016 at 11:20:09AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > On Wed, Sep 07, 2016 at 10:27:34AM +0200, Michael J Gruber wrote:
> >
> >> Now, I can't reproduce C on Linux[*], so there is more involved. It
> >> could be that my patch just exposes a problem in our start
Jeff King writes:
> On Wed, Sep 07, 2016 at 10:27:34AM +0200, Michael J Gruber wrote:
>
>> Now, I can't reproduce C on Linux[*], so there is more involved. It
>> could be that my patch just exposes a problem in our start_command()
>> etc.: run-command.c contains a lot of ifdefing, so possibly qui
Jeff King venit, vidit, dixit 07.09.2016 10:39:
> On Wed, Sep 07, 2016 at 10:27:34AM +0200, Michael J Gruber wrote:
>
>> Now, I can't reproduce C on Linux[*], so there is more involved. It
>> could be that my patch just exposes a problem in our start_command()
>> etc.: run-command.c contains a lot
On Wed, Sep 07, 2016 at 10:27:34AM +0200, Michael J Gruber wrote:
> Now, I can't reproduce C on Linux[*], so there is more involved. It
> could be that my patch just exposes a problem in our start_command()
> etc.: run-command.c contains a lot of ifdefing, so possibly quite
> different code is run
Johannes Schindelin venit, vidit, dixit 06.09.2016 18:43:
> Hi Michael,
>
> okay, final mail on this issue today:
>
> On Tue, 6 Sep 2016, Johannes Schindelin wrote:
>
>> Your original issue seemed to be that the gpg command could succeed, but
>> still no signature be seen. There *must* be a way
Hi Michael,
okay, final mail on this issue today:
On Tue, 6 Sep 2016, Johannes Schindelin wrote:
> Your original issue seemed to be that the gpg command could succeed, but
> still no signature be seen. There *must* be a way to test whether the
> called program added a signature, simply by testin
Hi Michael,
On Tue, 6 Sep 2016, Johannes Schindelin wrote:
> On Tue, 6 Sep 2016, Michael J Gruber wrote:
>
> > A full blown approach would use --status-fd=4 or such rather than hijacking
> > stderr.
> > This would require an extension of pipe_command() etc. to handle yet
> > another fd.
For t
Hi Michael,
On Tue, 6 Sep 2016, Michael J Gruber wrote:
> efee955 ("gpg-interface: check gpg signature creation status",
> 2016-06-17) used stderr to capture gpg's status output, which is the
> only reliable way for status checks. As a side effect, stderr was not
> shown to the user any more.
>
12 matches
Mail list logo
