From: "brian m. carlson" <sandals@crustytoothpaste.net>
To: Derrick Stolee <stolee@gmail.com>
Cc: git@vger.kernel.org, Taylor Blau <me@ttaylorr.com>,
Derrick Stolee <dstolee@microsoft.com>
Subject: Re: [PATCH 26/26] midx: switch to using the_hash_algo
Date: Fri, 23 Aug 2019 02:17:57 +0000 [thread overview]
Message-ID: <20190823021757.GL365197@genre.crustytoothpaste.net> (raw)
In-Reply-To: <4f6b781b-68b8-5bc4-92a2-67caff32024f@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1557 bytes --]
On 2019-08-22 at 14:04:16, Derrick Stolee wrote:
> On 8/18/2019 4:04 PM, brian m. carlson wrote:
> > diff --git a/midx.c b/midx.c
> > index d649644420..f29afc0d2d 100644
> > --- a/midx.c
> > +++ b/midx.c
> > @@ -19,8 +19,7 @@
> > #define MIDX_BYTE_NUM_PACKS 8
> > #define MIDX_HASH_VERSION 1
>
> This hash version "1" is the same as we used in the commit-graph. It's
> a byte value from the file format, and we've already discussed how it
> would have been better to use the 4-byte identifier, but that ship has
> sailed. I'm just pointing this out to say that we are not done in this
> file yet, but we can get to that when we want to test the midx with
> multiple hash lengths.
My approach so far has been to assume everything in the .git directory
is in the same hash except for the translation functionality. Therefore,
it doesn't make sense to distinguish between hashes in the midx files,
because we'll never have files that differ in hash. So essentially the
MIDX_HASH_VERSION being 1 is "whatever hash is being used in the .git
directory", not just SHA-1.
In addition, the current multi-pack index format isn't capable (from my
reading of the documentation, at least) of handling multiple hash
algorithms at once. So we'd need a midx v2 format for folks who are
using SHA-256 with SHA-1 compatibility and we could then write separate
sets of object chunks with an appropriate format identifier, much like
the proposed pack index v3.
--
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-08-23 2:18 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-18 20:04 [PATCH 00/26] object_id part 17 brian m. carlson
2019-08-18 20:04 ` [PATCH 01/26] builtin/replace: make hash size independent brian m. carlson
2019-08-18 20:04 ` [PATCH 02/26] patch-id: convert to use the_hash_algo brian m. carlson
2019-08-20 21:12 ` René Scharfe
2019-08-20 22:36 ` brian m. carlson
2019-08-22 15:53 ` Junio C Hamano
2019-08-18 20:04 ` [PATCH 03/26] fetch-pack: use parse_oid_hex brian m. carlson
2019-08-18 20:04 ` [PATCH 04/26] builtin/receive-pack: switch to use the_hash_algo brian m. carlson
2019-08-18 20:04 ` [PATCH 05/26] builtin/blame: switch uses of GIT_SHA1_HEXSZ to the_hash_algo brian m. carlson
2019-08-18 20:04 ` [PATCH 06/26] builtin/rev-parse: switch to use the_hash_algo brian m. carlson
2019-08-18 20:04 ` [PATCH 07/26] blame: remove needless comparison with GIT_SHA1_HEXSZ brian m. carlson
2019-08-18 20:04 ` [PATCH 08/26] show-index: switch hard-coded constants to the_hash_algo brian m. carlson
2019-08-18 20:04 ` [PATCH 09/26] connected: switch GIT_SHA1_HEXSZ " brian m. carlson
2019-08-18 20:04 ` [PATCH 10/26] bundle: switch to use the_hash_algo brian m. carlson
2019-08-18 20:04 ` [PATCH 11/26] combine-diff: replace GIT_SHA1_HEXSZ with the_hash_algo brian m. carlson
2019-08-18 20:04 ` [PATCH 12/26] config: use the_hash_algo in abbrev comparison brian m. carlson
2019-08-18 20:04 ` [PATCH 13/26] sha1-lookup: switch hard-coded constants to the_hash_algo brian m. carlson
2019-08-18 20:04 ` [PATCH 14/26] bisect: switch to using the_hash_algo brian m. carlson
2019-08-18 20:04 ` [PATCH 15/26] sequencer: convert to use the_hash_algo brian m. carlson
2019-08-18 20:04 ` [PATCH 16/26] pack-write: use hash_to_hex when writing checksums brian m. carlson
2019-08-18 20:04 ` [PATCH 17/26] builtin/repack: write object IDs of the proper length brian m. carlson
2019-08-18 20:04 ` [PATCH 18/26] builtin/worktree: switch null_sha1 to null_oid brian m. carlson
2019-08-18 20:04 ` [PATCH 19/26] cache: remove null_sha1 brian m. carlson
2019-08-18 20:04 ` [PATCH 20/26] wt-status: convert struct wt_status to object_id brian m. carlson
2019-08-18 20:04 ` [PATCH 21/26] packfile: replace sha1_to_hex brian m. carlson
2019-08-18 20:04 ` [PATCH 22/26] builtin/index-pack: " brian m. carlson
2019-08-18 20:04 ` [PATCH 23/26] builtin/receive-pack: " brian m. carlson
2019-08-18 20:04 ` [PATCH 24/26] rerere: " brian m. carlson
2019-08-18 20:04 ` [PATCH 25/26] builtin/show-index: " brian m. carlson
2019-08-18 20:04 ` [PATCH 26/26] midx: switch to using the_hash_algo brian m. carlson
2019-08-22 14:04 ` Derrick Stolee
2019-08-23 2:17 ` brian m. carlson [this message]
2019-08-23 11:53 ` Derrick Stolee
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=20190823021757.GL365197@genre.crustytoothpaste.net \
--to=sandals@crustytoothpaste.net \
--cc=dstolee@microsoft.com \
--cc=git@vger.kernel.org \
--cc=me@ttaylorr.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.
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).