From: Eric Blake <eblake@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Kevin Wolf <kwolf@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>,
QEMU Developers <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [PATCH] crypto: extend unit tests to cover decryption too
Date: Mon, 20 Jul 2015 16:16:21 -0600 [thread overview]
Message-ID: <55AD7335.1080703@redhat.com> (raw)
In-Reply-To: <CAFEAcA9G2xdkBV22wHWMJ29Lm2dLiZEcV9U3m+jyu+U2pPbH3g@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2315 bytes --]
On 07/20/2015 03:37 PM, Peter Maydell wrote:
> On 20 July 2015 at 21:57, Eric Blake <eblake@redhat.com> wrote:
>> On 07/20/2015 11:28 AM, Daniel P. Berrange wrote:
>>> The current unit test only verify the encryption API, which
>>
>> grammatical mismatch; you want either:
>> tests only verify
>> test only verifies
>>
>>> resulted in us missing a recently introduced bug in the
>>> decryption API from commit d3462e3. It was fortunately
>>> later discovered & fixed by commit bd0959 thanks to the
>>
>> Is a 6-byte SHA going to stay unambiguous long enough? git defaults to
>> 7-byte to reduce chances of collisions by 16.
>
> Fortunately causality allows us to disambiguate by knowing
> that Daniel can only be referring to a commit that's
> already happened rather than one in the future :-)
True, but that doesn't mean git makes it easy to disambiguate. When, in
the future, resolving the short name becomes ambiguous, how do you coax
git into showing the full SHA of both (or all) candidates, as well as
the date they were created, so you can then compare dates to the commit
message you are reading and deduce which one was meant?
$ git rev-parse ffff
error: short SHA1 ffff is ambiguous.
ffff
error: short SHA1 ffff is ambiguous.
fatal: ambiguous argument 'ffff': unknown revision or path not in the
working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'
/me goes and reads the man page
Hmm - this is something I've never used before:
$ git rev-parse --disambiguate=ffff
ffffb8c0bd544ab479a7a32a208d9de13aff62d9
ffffbf79aa11e013e8fd14ffb134faee6489b42c
ffffff01466a0180de7632842cf583c8a9cbf959
ffffbb369f3ed9bca5ff2867143f76d0c6e069c0
But that still doesn't tell you that two of those are blobs, and two of
them commits, nor what dates the commits have, in a way that can easily
determine if one of the commits was an ancestor of the point where a
(hypothetical) commit message referred to a (once-non-ambiguous) short
reference.
And (straying off-topic for this list) why does 'git rev-parse
--disambiguate ffff' not behave the same as 'git rev-parse
--disambiguate=ffff'?
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]
prev parent reply other threads:[~2015-07-20 22:16 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-20 17:28 [Qemu-devel] [PATCH] crypto: extend unit tests to cover decryption too Daniel P. Berrange
2015-07-20 20:57 ` Eric Blake
2015-07-20 21:37 ` Peter Maydell
2015-07-20 22:16 ` Eric Blake [this message]
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=55AD7335.1080703@redhat.com \
--to=eblake@redhat.com \
--cc=kwolf@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).