From: "brian m. carlson" <sandals@crustytoothpaste.net>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Cc: git@vger.kernel.org, "René Scharfe" <l.s.r@web.de>,
"Duy Nguyen" <pclouds@gmail.com>
Subject: Re: [PATCH 28/31] dir: make untracked cache extension hash size independent
Date: Wed, 13 Feb 2019 00:30:42 +0000 [thread overview]
Message-ID: <20190213003041.GI684736@genre.crustytoothpaste.net> (raw)
In-Reply-To: <87y36ljmcu.fsf@evledraar.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1609 bytes --]
On Tue, Feb 12, 2019 at 12:08:01PM +0100, Ævar Arnfjörð Bjarmason wrote:
> Both this & the follow-up 29/31 look scary since this is an on-disk
> structure and this patch & the next one rather than implementing some
> transition, just changes the structs & code we use to read & write to
> use the current hash size.
>
> So what are we going to do when the "current" size is SHA-256 and our
> on-disk cache is SHA-1? It seems like with this we'd at best (I haven't
> tested) throw away the SHA-1 UC data, and at worst introduce some silent
> persistent read failure.
That's a good question. The current design has everything in the .git
directory other than the loose object table and the pack indices in one
algorithm. That is, the untracked cache extension, like the rest of the
index, will always be SHA-256 when the objects are stored in SHA-256.
Having mixed algorithms in the .git directory would add a lot of
complexity.
> In any case that seems like something we should have tests for with an
> on-disk format, i.e. write in one hash, see what happens when we read in
> another, and perhaps instead of not understanding SHA-1 hashes in
> SHA-256 mode we'd read the SHA-1 and consult the SHA-1<->SHA-256 lookup
> table we're going to be eventually maintaining on the side?
Correct. The current plan is that when the transition code is fully
implemented, we'll read object IDs from the user in whatever algorithms
we support, translate them into the default algorithm, and then use
them.
--
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 868 bytes --]
next prev parent reply other threads:[~2019-02-13 0:30 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-12 1:22 [PATCH 00/31] Hash function transition part 16 brian m. carlson
2019-02-12 1:22 ` [PATCH 01/31] t/lib-submodule-update: use appropriate length constant brian m. carlson
2019-02-12 1:22 ` [PATCH 02/31] pack-bitmap: make bitmap header handling hash agnostic brian m. carlson
2019-02-12 1:22 ` [PATCH 03/31] pack-bitmap: convert struct stored_bitmap to object_id brian m. carlson
2019-02-12 1:22 ` [PATCH 04/31] pack-bitmap: replace sha1_to_hex brian m. carlson
2019-02-12 6:37 ` Jeff King
2019-02-13 0:00 ` brian m. carlson
2019-02-14 4:41 ` Jeff King
2019-02-12 1:22 ` [PATCH 05/31] pack-bitmap: switch hard-coded constants to the_hash_algo brian m. carlson
2019-02-12 11:13 ` Ævar Arnfjörð Bjarmason
2019-02-12 1:22 ` [PATCH 06/31] submodule: avoid hard-coded constants brian m. carlson
2019-02-12 1:22 ` [PATCH 07/31] notes-merge: switch to use the_hash_algo brian m. carlson
2019-02-12 1:22 ` [PATCH 08/31] notes: make hash size independent brian m. carlson
2019-02-12 1:37 ` Eric Sunshine
2019-02-12 1:42 ` brian m. carlson
2019-02-12 1:22 ` [PATCH 09/31] notes: replace sha1_to_hex brian m. carlson
2019-02-12 1:22 ` [PATCH 10/31] object-store: rename and expand packed_git's sha1 member brian m. carlson
2019-02-12 3:32 ` Eric Sunshine
2019-02-14 3:33 ` brian m. carlson
2019-02-12 1:22 ` [PATCH 11/31] builtin/name-rev: make hash-size independent brian m. carlson
2019-02-12 1:22 ` [PATCH 12/31] fast-import: " brian m. carlson
2019-02-12 3:44 ` Eric Sunshine
2019-02-12 23:36 ` brian m. carlson
2019-02-12 1:22 ` [PATCH 13/31] fast-import: replace sha1_to_hex brian m. carlson
2019-02-12 1:22 ` [PATCH 14/31] builtin/am: make hash size independent brian m. carlson
2019-02-12 1:22 ` [PATCH 15/31] builtin/pull: make hash-size independent brian m. carlson
2019-02-12 3:47 ` Eric Sunshine
2019-02-12 1:22 ` [PATCH 16/31] http-push: convert to use the_hash_algo brian m. carlson
2019-02-12 1:22 ` [PATCH 17/31] http-backend: allow 64-character hex names brian m. carlson
2019-02-12 1:22 ` [PATCH 18/31] http-push: remove remaining uses of sha1_to_hex brian m. carlson
2019-02-12 1:22 ` [PATCH 19/31] http-walker: replace sha1_to_hex brian m. carlson
2019-02-12 3:51 ` Eric Sunshine
2019-02-12 1:22 ` [PATCH 20/31] http: replace hard-coded constant with the_hash_algo brian m. carlson
2019-02-12 1:22 ` [PATCH 21/31] http: compute hash of downloaded objects using the_hash_algo brian m. carlson
2019-02-12 1:22 ` [PATCH 22/31] http: replace sha1_to_hex brian m. carlson
2019-02-12 1:22 ` [PATCH 23/31] remote-curl: make hash size independent brian m. carlson
2019-02-12 11:11 ` Ævar Arnfjörð Bjarmason
2019-02-12 1:22 ` [PATCH 24/31] archive-tar: " brian m. carlson
2019-02-12 7:20 ` René Scharfe
2019-02-12 17:33 ` René Scharfe
2019-02-13 0:11 ` brian m. carlson
2019-02-12 1:22 ` [PATCH 25/31] archive: convert struct archiver_args to object_id brian m. carlson
2019-02-12 1:22 ` [PATCH 26/31] refspec: make hash size independent brian m. carlson
2019-02-12 1:22 ` [PATCH 27/31] builtin/difftool: use parse_oid_hex brian m. carlson
2019-02-12 8:27 ` Eric Sunshine
2019-02-12 1:22 ` [PATCH 28/31] dir: make untracked cache extension hash size independent brian m. carlson
2019-02-12 11:08 ` Ævar Arnfjörð Bjarmason
2019-02-13 0:30 ` brian m. carlson [this message]
2019-02-12 1:22 ` [PATCH 29/31] read-cache: read data in a hash-independent way brian m. carlson
2019-02-12 1:22 ` [PATCH 30/31] Git.pm: make hash size independent brian m. carlson
2019-02-12 10:59 ` Ævar Arnfjörð Bjarmason
2019-02-18 19:09 ` brian m. carlson
2019-02-18 21:00 ` Ævar Arnfjörð Bjarmason
2019-02-12 1:22 ` [PATCH 31/31] gitweb: " brian m. carlson
2019-02-12 10:57 ` Ævar Arnfjörð Bjarmason
2019-02-12 11:15 ` [PATCH 00/31] Hash function transition part 16 Ævar Arnfjörð Bjarmason
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=20190213003041.GI684736@genre.crustytoothpaste.net \
--to=sandals@crustytoothpaste.net \
--cc=avarab@gmail.com \
--cc=git@vger.kernel.org \
--cc=l.s.r@web.de \
--cc=pclouds@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.
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).