From: Junio C Hamano <gitster@pobox.com>
To: "brian m. carlson" <sandals@crustytoothpaste.net>
Cc: <git@vger.kernel.org>
Subject: Re: [RFC PATCH 6/6] hex: allow only lowercase object IDs in breaking changes mode
Date: Tue, 25 Aug 2026 09:36:30 -0700 [thread overview]
Message-ID: <xmqq8q5unomp.fsf@gitster.g> (raw)
In-Reply-To: <20260729233215.398654-7-sandals@crustytoothpaste.net> (brian m. carlson's message of "Wed, 29 Jul 2026 23:32:15 +0000")
"brian m. carlson" <sandals@crustytoothpaste.net> writes:
> IDs. Note that in t5324, we change the hex character from "A" to "b"
> because in SHA-256 mode, "a" is the correct value, so our test_must_fail
> assertion will unexpectedly succeed in that case.
This was a bit hard to read and puzzled me, as you have two "A" and
change only one of them to "b".
Is the idea that we wanted to make sure we use lowercase letters,
because we do not want to see the tested "verify" command fail for
now-forbidden uppercase hex but we want the command to read the data
as valid hex and fail because it notices the corruption? So the
first hunk is a no-op change (i.e., the first hash identifier on the
first line is corrupt with the 30-th char in the file replaced with
either 'a' or 'A'), while the second hunk is not (i.e., the second
hash identifier on the second line in the file is corrupt with the
70-th char in the file replaced with 'A' but it is OK with 'a'
because in the SHA-256 mode, the correct character for the place
happens to be 'a')? It is puzzling if that is the case, because
what this series wanted to tighten was that we used to treat hex
chars case insensitively. So, if 'a' happened to be the right
uncorrupted value for position 70, how did the original that
replaced it to 'A' tested a "corrupted" state?
> diff --git a/t/t5324-split-commit-graph.sh b/t/t5324-split-commit-graph.sh
> index bf7ba0e558..29db815c77 100755
> --- a/t/t5324-split-commit-graph.sh
> +++ b/t/t5324-split-commit-graph.sh
> @@ -349,7 +349,7 @@ test_expect_success 'verify after commit-graph-chain corruption (base)' '
> test_must_fail git commit-graph verify 2>test_err &&
> grep -v "^+" test_err >err &&
> test_grep "invalid commit-graph chain" err &&
> - corrupt_file "$graphdir/commit-graph-chain" 30 "A" &&
> + corrupt_file "$graphdir/commit-graph-chain" 30 "a" &&
> test_must_fail git commit-graph verify 2>test_err &&
> grep -v "^+" test_err >err &&
> test_grep "unable to find all commit-graph files" err
> @@ -364,7 +364,7 @@ test_expect_success 'verify after commit-graph-chain corruption (tip)' '
> test_must_fail git commit-graph verify 2>test_err &&
> grep -v "^+" test_err >err &&
> test_grep "invalid commit-graph chain" err &&
> - corrupt_file "$graphdir/commit-graph-chain" 70 "A" &&
> + corrupt_file "$graphdir/commit-graph-chain" 70 "b" &&
> test_must_fail git commit-graph verify 2>test_err &&
> grep -v "^+" test_err >err &&
> test_grep "unable to find all commit-graph files" err
next prev parent reply other threads:[~2026-08-25 16:36 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-29 23:32 [RFC PATCH 0/6] Git 3.0: restrict hex object IDs to lowercase only brian m. carlson
2026-07-29 23:32 ` [RFC PATCH 1/6] hex: add functionality for lowercase-only hex brian m. carlson
2026-07-31 7:38 ` Junio C Hamano
2026-08-25 15:39 ` Junio C Hamano
2026-08-25 21:44 ` brian m. carlson
2026-07-29 23:32 ` [RFC PATCH 2/6] hex: allow specifying hex type with hex2chr brian m. carlson
2026-07-29 23:32 ` [RFC PATCH 3/6] hex: make hex_to_bytes accept kind of hex to use brian m. carlson
2026-07-31 7:38 ` Junio C Hamano
2026-08-01 14:35 ` Jeff King
2026-07-29 23:32 ` [RFC PATCH 4/6] hex: label usages of hex parsing for object IDs brian m. carlson
2026-07-31 3:24 ` Junio C Hamano
2026-08-25 16:11 ` Junio C Hamano
2026-07-29 23:32 ` [RFC PATCH 5/6] object-name: use hexval brian m. carlson
2026-08-25 16:19 ` Junio C Hamano
2026-08-25 19:44 ` Elijah Newren
2026-08-25 21:41 ` brian m. carlson
2026-07-29 23:32 ` [RFC PATCH 6/6] hex: allow only lowercase object IDs in breaking changes mode brian m. carlson
2026-07-31 7:48 ` Junio C Hamano
2026-07-31 12:33 ` Junio C Hamano
2026-08-02 22:09 ` brian m. carlson
2026-08-04 19:32 ` Junio C Hamano
2026-08-04 21:46 ` brian m. carlson
2026-08-05 3:09 ` Michael Montalbo
2026-08-25 9:04 ` Phillip Wood
2026-08-25 21:36 ` brian m. carlson
2026-08-25 16:36 ` Junio C Hamano [this message]
2026-08-25 19:44 ` Elijah Newren
2026-07-30 8:21 ` [RFC PATCH 0/6] Git 3.0: restrict hex object IDs to lowercase only Junio C Hamano
2026-07-30 21:18 ` brian m. carlson
2026-08-01 14:45 ` Jeff King
2026-08-01 18:22 ` Junio C Hamano
2026-08-02 21:55 ` 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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqq8q5unomp.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.