On Fri, Mar 24, 2017 at 11:04:27AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > It seems like t7030 should just skip_all when the GPG prereq is not
> > met (it's not wrong to mark each test that's added, but it would have
> > made this particular mistake harder).
>
> I'd leave that to
On Fri, Mar 24, 2017 at 12:49:43PM -0400, Jeff King wrote:
> On Fri, Mar 24, 2017 at 09:45:30AM -0700, Junio C Hamano wrote:
>
> > I actually think this uncovers another class of breakage. t7030
> > tests should be protected with GPG prereq and 'fourth-signed' that
> > is made only with the prer
Jeff King writes:
> It seems like t7030 should just skip_all when the GPG prereq is not
> met (it's not wrong to mark each test that's added, but it would have
> made this particular mistake harder).
I'd leave that to be done by others after the dust settles ;-).
Here is what I have right now
On Fri, Mar 24, 2017 at 09:45:30AM -0700, Junio C Hamano wrote:
> I actually think this uncovers another class of breakage. t7030
> tests should be protected with GPG prereq and 'fourth-signed' that
> is made only with the prereq in the first test will not be found.
It seems like t7030 should ju
Jeff King writes:
> On Thu, Mar 23, 2017 at 03:00:08PM -0700, Junio C Hamano wrote:
>
>> Santiago Torres writes:
>>
>> > This sounds like a helpful addition to implement. We could update/add
>> > tests for compliance on this once the feature is addded and fix the
>> > ambiguous behavior in the
On Thu, Mar 23, 2017 at 03:00:08PM -0700, Junio C Hamano wrote:
> Santiago Torres writes:
>
> > This sounds like a helpful addition to implement. We could update/add
> > tests for compliance on this once the feature is addded and fix the
> > ambiguous behavior in the tests now.
>
> OK, so has e
On Thu, Mar 23, 2017 at 03:00:08PM -0700, Junio C Hamano wrote:
> Santiago Torres writes:
> OK, so has everybody agreed what the next step would be?
I believe it is, although I imagine getting a confirmation from Peff
would be adequate.
> Is the patch below a good first step (I still need to
Santiago Torres writes:
> This sounds like a helpful addition to implement. We could update/add
> tests for compliance on this once the feature is addded and fix the
> ambiguous behavior in the tests now.
OK, so has everybody agreed what the next step would be? Is the
patch below a good first s
On Wed, Mar 22, 2017 at 06:41:24PM -0400, Jeff King wrote:
> > In that case, something like this would be closer to the desired
> > behavior?
>
> Yes, though you can spell:
>
> cat >expect <<-\EOF
> EOF
>
> as just:
>
> >expect
Ah, that sounds like a better way to fix this with a smaller
Jeff King writes:
> OTOH, we could perhaps make the rule "ignored unless %(gpg) formatters
> are used". Which would be backwards-compatible and safe for old formats,
> and work correctly for new ones.
Yup, that is a very sensible escape hatch that we can use later.
Thanks.
On Wed, Mar 22, 2017 at 06:34:43PM -0400, Santiago Torres wrote:
> > I worked up the patch to do that (see below), but I got stumped trying
> > to write the commit message. Perhaps that is what the test intended, but
> > I don't think tag's --format understands "%G" codes at all. So you
> > cannot
Jeff King writes:
> I worked up the patch to do that (see below), but I got stumped trying
> to write the commit message. Perhaps that is what the test intended, but
> I don't think tag's --format understands "%G" codes at all.
> So you cannot tell from the output if a tag was valid or not; you h
> I worked up the patch to do that (see below), but I got stumped trying
> to write the commit message. Perhaps that is what the test intended, but
> I don't think tag's --format understands "%G" codes at all. So you
> cannot tell from the output if a tag was valid or not; you have to check
> the e
On Wed, Mar 22, 2017 at 06:15:57PM -0400, Santiago Torres wrote:
> > > Like 2/3, this one also produces test failures for me. It looks like
> > > "verify-tag" does not show a tag which has been forged. I'm not sure if
> > > that's intentional (and the test is wrong) or a bug. +cc Santiago
> >
>
On Wed, Mar 22, 2017 at 03:04:32PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > On Wed, Mar 22, 2017 at 01:08:05PM -0700, Junio C Hamano wrote:
> >
> >> From: Jan Palus
> >>
> >> These all came as part of an earlier st/verify-tag topic that was
> >> merged to 2.12.
> >>
> >> Signed-o
Jeff King writes:
> On Wed, Mar 22, 2017 at 01:08:05PM -0700, Junio C Hamano wrote:
>
>> From: Jan Palus
>>
>> These all came as part of an earlier st/verify-tag topic that was
>> merged to 2.12.
>>
>> Signed-off-by: Junio C Hamano
>> ---
>>
>> * This should be applied on top of 4fea72f4 ("
On Wed, Mar 22, 2017 at 05:43:57PM -0400, Santiago Torres wrote:
> > Like 2/3, this one also produces test failures for me. It looks like
> > "verify-tag" does not show a tag which has been forged. I'm not sure if
> > that's intentional (and the test is wrong) or a bug.
>
> I see that offending
On Wed, Mar 22, 2017 at 05:10:03PM -0400, Jeff King wrote:
> On Wed, Mar 22, 2017 at 01:08:05PM -0700, Junio C Hamano wrote:
>
> > From: Jan Palus
> >
> > These all came as part of an earlier st/verify-tag topic that was
> > merged to 2.12.
> >
> > Signed-off-by: Junio C Hamano
> > ---
> >
>
On Wed, Mar 22, 2017 at 01:08:05PM -0700, Junio C Hamano wrote:
> From: Jan Palus
>
> These all came as part of an earlier st/verify-tag topic that was
> merged to 2.12.
>
> Signed-off-by: Junio C Hamano
> ---
>
> * This should be applied on top of 4fea72f4 ("t/t7004-tag: Add
>--format s
From: Jan Palus
These all came as part of an earlier st/verify-tag topic that was
merged to 2.12.
Signed-off-by: Junio C Hamano
---
* This should be applied on top of 4fea72f4 ("t/t7004-tag: Add
--format specifier tests", 2017-01-17)
t/t7004-tag.sh| 8
t/t7030-verify-tag
20 matches
Mail list logo
