From: Derrick Stolee <stolee@gmail.com>
To: "brian m. carlson" <sandals@crustytoothpaste.net>,
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 07:53:38 -0400 [thread overview]
Message-ID: <244c8006-d8fa-8440-e799-ba8e41eb40cb@gmail.com> (raw)
In-Reply-To: <20190823021757.GL365197@genre.crustytoothpaste.net>
On 8/22/2019 10:17 PM, brian m. carlson wrote:
> 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.
Absolutely, it is not. It would be a great place to store a transition
table, when that is needed.
If we _never_ allow both hashes in the .git folder, then maybe we won't
ever need this and can rely on config options. I imagine that will be
tricky, and updating this byte should only help. We are not ready for
that, anyway.
Thanks,
-Stolee
prev parent reply other threads:[~2019-08-23 11:53 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
2019-08-23 11:53 ` Derrick Stolee [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=244c8006-d8fa-8440-e799-ba8e41eb40cb@gmail.com \
--to=stolee@gmail.com \
--cc=dstolee@microsoft.com \
--cc=git@vger.kernel.org \
--cc=me@ttaylorr.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.
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).