All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michał Górny" <mgorny@gentoo.org>
To: Junio C Hamano <gitster@pobox.com>
Cc: Derrick Stolee <stolee@gmail.com>,
	"git@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: Git Test Coverage Report (Friday, Nov 2)
Date: Sat, 03 Nov 2018 17:22:32 +0100	[thread overview]
Message-ID: <1541262152.1028.20.camel@gentoo.org> (raw)
In-Reply-To: <xmqqr2g2mqaq.fsf@gitster-ct.c.googlers.com>

[-- Attachment #1: Type: text/plain, Size: 1643 bytes --]

On Sat, 2018-11-03 at 19:03 +0900, Junio C Hamano wrote:
> Michał Górny <mgorny@gentoo.org> writes:
> 
> > As for how involved... we'd just have to use a key that has split
> > signing subkey.  Would it be fine to add the subkey to the existing key?
> >  It would imply updating keyids/fingerprints everywhere.
> 
> Yes, that "everywhere" is exactly what I meant by "how involved",
> and your suggestion answers "very much involved".
> 
> If we can easily add _another_ key with a subkey that is not the
> primary one we use for other tests, without touching the existing
> key and the existing tests that use it (including the one I touched
> below--- we'd want to see a sig with a key that is not split is
> shown with the same %GF and %GP), while adding a handful of new
> tests that create signed objects under the new & split key and 
> view them with %GF and %GP, then the end result would be that we
> managed to add a new test case where %GF/%GP are different without
> making very much involved changes.  I guess that was what I was
> getting at.
> 

I've just did a little research and came to the following results:

1. modifying the 'C. O. Mitter' key would require changes to 4 tests,

2. modifying the 'Eris Discordia' key would require changes to 2 tests
   (both in 7510).

Do you think 2. would be an acceptable option?  I think changing 2 tests
would be preferable to proliferating a third key for one test case. 
Also, given that both failing tests are specifically format string
tests, one of them would serve additional purpose of testing %GP!=%GF.

-- 
Best regards,
Michał Górny

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

  reply	other threads:[~2018-11-03 16:22 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-03  2:16 Git Test Coverage Report (Friday, Nov 2) Derrick Stolee
2018-11-03  3:38 ` Junio C Hamano
2018-11-03  7:57   ` Michał Górny
2018-11-03 10:03     ` Junio C Hamano
2018-11-03 16:22       ` Michał Górny [this message]
2018-11-04  9:17         ` Junio C Hamano
2018-11-03 11:47 ` SZEDER Gábor

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=1541262152.1028.20.camel@gentoo.org \
    --to=mgorny@gentoo.org \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=stolee@gmail.com \
    /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.