From: "Eric W. Biederman" <ebiederm@xmission•com>
To: "brian m. carlson" <sandals@crustytoothpaste•net>
Cc: Junio C Hamano <gitster@pobox•com>, git@vger•kernel.org
Subject: Re: [RFC][PATCH 0/32] SHA256 and SHA1 interoperability
Date: Tue, 12 Sep 2023 16:19:13 -0500 [thread overview]
Message-ID: <87v8cfxf72.fsf@email.froward.int.ebiederm.org> (raw)
In-Reply-To: <ZP+PKa3N1N1PXROM@tapette.crustytoothpaste.net> (brian m. carlson's message of "Mon, 11 Sep 2023 22:05:29 +0000")
"brian m. carlson" <sandals@crustytoothpaste•net> writes:
> On 2023-09-11 at 16:13:27, Eric W. Biederman wrote:
>> Junio, brian for the very warm reception of this, it is very
>> encouraging.
>>
>> I am not worried about what it will take time to get the changes I
>> posted into the integration. I had only envisioned them as good enough
>> to get the technical ideas across, and had never envisioned them as
>> being accepted as is.
>>
>> What I am envisioning as my future directions are:
>>
>> - Post non controversial cleanups, so they can be merged.
>> (I can only see about 4 of them the most significant is:
>> bulk-checkin: Only accept blobs)
>>
>> - Sort out the configuration options
>>
>> - Post the smallest patchset I can that will allow testing the code in
>> object-file-convert.c. Unfortunately for that I need configuration
>> options to enable the mapping.
>>
>> In starting to write the tests I have already found a bug in
>> the conversion of tags (an extra newline is added), and I haven't
>> even gotten to testing the tricky bits with signatures.
>
> I wonder if unit tests are a possibility here now that we're starting to
> use them. They're not obligatory, of course, but it may be more
> convenient for you if they turn out to be a suitable option. If not, no
> big deal.
I believe you mean using test-tool and making a very narrow focused test
on just the functionality.
If the number of patches I have to go through before I can test anything
becomes a problem I might go there. Unfortunately it would take some
refactoring to make object-file-convert independent of the object
mapping layer, and that is extra work and is likely to introduces bugs
as anything.
I have managed to get a set of tests working. I am just going through
now and plugging the holes.
My big strategy for testing convert_object_file is to build two
repositories one sha1 and the other sha256 both with compatibility
support enabled. I add a series of objects to those repositories and
compare them to ensure the objects are identical.
It is working well and is finding bugs not just in convert_object_file
but in code such as commit and tag that perform interesting work with
signed commits.
I discovered I had bungled the placement of hash_object_file for
the compatibility hash in commit.
I found that git tag did not yet support building tags with both
hash algorithms.
Right now I am looking at commits with mergetag lines. It is not fun.
The mergetag instead of pointing to the tag objects they include the
body of the tag objects in the commit object. So I have convert
the embedded tag objects from one hash function to another.
Which given the presence of preceding space on every line of
the embedded tag object makes it doubly interesting. Perhaps
someone has already written code to extract the embedded tag.
Or in short everything is moving along steadily.
Eric
next prev parent reply other threads:[~2023-09-12 21:19 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-08 23:05 [RFC][PATCH 0/32] SHA256 and SHA1 interoperability Eric W. Biederman
2023-09-08 23:10 ` [PATCH 01/32] doc hash-file-transition: A map file for mapping between sha1 and sha256 Eric W. Biederman
2023-09-10 14:24 ` brian m. carlson
2023-09-10 18:07 ` Eric W. Biederman
2023-09-12 0:14 ` brian m. carlson
2023-09-12 13:36 ` Eric W. Biederman
2023-09-08 23:10 ` [PATCH 02/32] doc hash-function-transition: Replace compatObjectFormat with compatMap Eric W. Biederman
2023-09-10 14:34 ` brian m. carlson
2023-09-10 18:00 ` Eric W. Biederman
2023-09-11 6:11 ` Junio C Hamano
2023-09-11 16:35 ` [PATCH v2 02/32] doc hash-function-transition: Replace compatObjectFormat with mapObjectFormat Eric W. Biederman
2023-09-11 23:46 ` [PATCH v3 02/32] doc hash-function-transition: Augment compatObjectFormat with readCompatMap Eric W. Biederman
2023-09-12 7:57 ` Oswald Buddenhagen
2023-09-12 12:11 ` Eric W. Biederman
2023-09-13 8:10 ` Oswald Buddenhagen
2023-09-08 23:10 ` [PATCH 03/32] object-file-convert: Stubs for converting from one object format to another Eric W. Biederman
2023-09-08 23:10 ` [PATCH 04/32] object-name: Initial support for ^{sha1} and ^{sha256} Eric W. Biederman
2023-09-08 23:10 ` [PATCH 05/32] repository: add a compatibility hash algorithm Eric W. Biederman
2023-09-08 23:10 ` [PATCH 06/32] repository: Implement core.compatMap Eric W. Biederman
2023-09-08 23:10 ` [PATCH 07/32] loose: add a mapping between SHA-1 and SHA-256 for loose objects Eric W. Biederman
2023-09-08 23:10 ` [PATCH 08/32] loose: Compatibilty short name support Eric W. Biederman
2023-09-08 23:10 ` [PATCH 09/32] object-file: Update the loose object map when writing loose objects Eric W. Biederman
2023-09-08 23:10 ` [PATCH 10/32] bulk-checkin: Only accept blobs Eric W. Biederman
2023-09-08 23:10 ` [PATCH 11/32] pack: Communicate the compat_oid through struct pack_idx_entry Eric W. Biederman
2023-09-08 23:10 ` [PATCH 12/32] bulk-checkin: hash object with compatibility algorithm Eric W. Biederman
2023-09-11 6:17 ` Junio C Hamano
2023-09-08 23:10 ` [PATCH 13/32] object-file: Add a compat_oid_in parameter to write_object_file_flags Eric W. Biederman
2023-09-08 23:10 ` [PATCH 14/32] commit: write commits for both hashes Eric W. Biederman
2023-09-11 6:25 ` Junio C Hamano
2023-09-08 23:10 ` [PATCH 15/32] cache: add a function to read an OID of a specific algorithm Eric W. Biederman
2023-09-08 23:10 ` [PATCH 16/32] object: Factor out parse_mode out of fast-import and tree-walk into in object.h Eric W. Biederman
2023-09-08 23:10 ` [PATCH 17/32] object-file-convert: add a function to convert trees between algorithms Eric W. Biederman
2023-09-08 23:10 ` [PATCH 18/32] object-file-convert: convert commit objects when writing Eric W. Biederman
2023-09-08 23:10 ` [PATCH 19/32] object-file-convert: convert tag commits " Eric W. Biederman
2023-09-08 23:10 ` [PATCH 20/32] builtin/cat-file: Let the oid determine the output algorithm Eric W. Biederman
2023-09-08 23:10 ` [PATCH 21/32] tree-walk: init_tree_desc take an oid to get the hash algorithm Eric W. Biederman
2023-09-08 23:10 ` [PATCH 22/32] object-file: Handle compat objects in check_object_signature Eric W. Biederman
2023-09-08 23:10 ` [PATCH 23/32] builtin/ls-tree: Let the oid determine the output algorithm Eric W. Biederman
2023-09-08 23:10 ` [PATCH 24/32] builtin/pack-objects: Communicate the compatibility hash through struct pack_idx_entry Eric W. Biederman
2023-09-08 23:10 ` [PATCH 25/32] pack-compat-map: Add support for .compat files of a packfile Eric W. Biederman
2023-09-11 6:30 ` Junio C Hamano
2023-10-05 18:14 ` Taylor Blau
2023-09-08 23:10 ` [PATCH 26/32] object-file-convert: Implement convert_object_file_{begin,step,end} Eric W. Biederman
2023-09-11 6:28 ` Junio C Hamano
2023-09-08 23:10 ` [PATCH 27/32] builtin/fast-import: compute compatibility hashs for imported objects Eric W. Biederman
2023-09-08 23:10 ` [PATCH 28/32] builtin/index-pack: Add a simple oid index Eric W. Biederman
2023-09-08 23:10 ` [PATCH 29/32] builtin/index-pack: Compute the compatibility hash Eric W. Biederman
2023-09-08 23:10 ` [PATCH 30/32] builtin/index-pack: Make the stack in compute_compat_oid explicit Eric W. Biederman
2023-09-08 23:10 ` [PATCH 31/32] unpack-objects: Update to compute and write the compatibility hashes Eric W. Biederman
2023-09-08 23:10 ` [PATCH 32/32] object-file-convert: Implement repo_submodule_oid_to_algop Eric W. Biederman
2023-09-09 12:58 ` [RFC][PATCH 0/32] SHA256 and SHA1 interoperability Eric W. Biederman
2023-09-10 15:38 ` brian m. carlson
2023-09-10 18:20 ` Eric W. Biederman
2023-09-11 6:37 ` Junio C Hamano
2023-09-11 16:13 ` Eric W. Biederman
2023-09-11 22:05 ` brian m. carlson
2023-09-12 21:19 ` Eric W. Biederman [this message]
2023-09-12 16:20 ` Junio C Hamano
2023-09-14 19:57 ` Eric W. Biederman
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=87v8cfxf72.fsf@email.froward.int.ebiederm.org \
--to=ebiederm@xmission$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=gitster@pobox$(echo .)com \
--cc=sandals@crustytoothpaste$(echo .)net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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