git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Stefan Beller <sbeller@google.com>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Cc: "brian m. carlson" <sandals@crustytoothpaste.net>,
	Junio C Hamano <gitster@pobox.com>,
	Git Mailing List <git@vger.kernel.org>
Subject: Re: [PATCH 2/2] t6500: mark tests as SHA1 reliant
Date: Mon, 31 Jul 2017 13:30:21 -0700	[thread overview]
Message-ID: <CAGZ79kZFkNu5zOZk_+ckkVNrU=7chHezPy0rA_A0-CjxFhucAw@mail.gmail.com> (raw)
In-Reply-To: <CACBZZX43JFOAOTffWVEMT1fPuzAiZnYi4JoE55QWquZ4kLA2Hg@mail.gmail.com>

On Mon, Jul 31, 2017 at 1:17 PM, Ævar Arnfjörð Bjarmason
<avarab@gmail.com> wrote:
> On Mon, Jul 31, 2017 at 1:24 AM, brian m. carlson
> <sandals@crustytoothpaste.net> wrote:
>> On Sun, Jul 30, 2017 at 11:00:19PM +0000, brian m. carlson wrote:
>>> Yes, basically, but a bit more generally.  There will always be cases in
>>> which we need to specify an object ID or an arbitrary string and the
>>> behavior will need to vary based on the hash.  That can be something
>>> like, in this case, the two blob contents that would have the similar
>>> prefix.
>>>
>>> So in this case, we pass the helper the string "263 410" and get back a
>>> value for either the hacked SHA-1 hash or the SHA-256 or whatever we're
>>> using.
>>
>> I realize this was worded poorly.  So for my example, in this case, we'd
>> do:
>>
>> test-helper-hash-string "263 410"
>>
>> For SHA-1, we'd get "263 410".  For SHA-256, we'd get "313 481" (which,
>> as SHA-256 blobs, both start with "17" in their hex representation).
>> Presumably we'd read some environment variable to determine the proper
>> value.
>
> I've been mostly out of the loop on this hash transition plan, but
> don't we expect to be compiling a git that knows about both SHA-1 and
> whatever the $newhash is?

That is my understanding as well.

> If so it seems better to just test all N
> hashes we have:
>
>     test_expect_success_hash $desc_description '
>         hash_value=$(test-helper-hash-string $CURRENT_HASH)
>         ....
>     '
>
> Then test_expect_success_hash would run N times for the N hashes we have.

I think that is just adding more workload without furthering the stated goal
which is usually reached with just one hash function. The tests we're talking
about here are not trying to test correctness of hashes but some other
functionality
(correct abbreviation length, collisions in prefix, etc.) that would not change
depending on the hash function used, I imagine.

For t0000 we want to have multiple versions, one for each hash.

> This would obviously be slightly more hassle to write & convert, but I
> think it would be worth it, particularly with something like Travis
> where we can test all hashes, instead of being in some mode where we
> fragment on all of hashes/gettext poison and whatever other
> compilation option we have that really requires compiling a new git
> version...

  reply	other threads:[~2017-07-31 20:30 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-28 17:18 [RFD PATCH 0/2] How to migrate our test infrastructure away from sha1 Stefan Beller
2017-07-28 17:18 ` [PATCH 1/2] alter hash function: expose test dependencies on sha1 Stefan Beller
2017-07-28 21:52   ` Junio C Hamano
2017-07-28 17:18 ` [PATCH 2/2] t6500: mark tests as SHA1 reliant Stefan Beller
2017-07-28 17:59   ` Junio C Hamano
2017-07-28 21:43     ` Stefan Beller
2017-07-28 22:14   ` Junio C Hamano
2017-07-29 17:58     ` brian m. carlson
2017-07-30 21:21       ` Junio C Hamano
2017-07-30 23:00         ` brian m. carlson
2017-07-30 23:24           ` brian m. carlson
2017-07-31 20:17             ` Ævar Arnfjörð Bjarmason
2017-07-31 20:30               ` Stefan Beller [this message]
2017-07-31 20:26             ` Stefan Beller
2017-07-31 23:54               ` brian m. carlson

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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAGZ79kZFkNu5zOZk_+ckkVNrU=7chHezPy0rA_A0-CjxFhucAw@mail.gmail.com' \
    --to=sbeller@google.com \
    --cc=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=sandals@crustytoothpaste.net \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).