Re: [RFC PATCH 0/6] Git 3.0: restrict hex object IDs to lowercase only

--jTRfy0c7VV0awmXZ
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On 2026-08-01 at 14:45:27, Jeff King wrote:
> Another interesting case is upper-case hex within objects:
>=20
>   $ git rev-parse HEAD
>   b85b9595a8136c79551340c3d73443a62eddd893
>=20
>   $ git cat-file commit HEAD |
>     perl -lpe '
>         if (/^parent (.*)/) {
> 		$_ =3D "parent " . uc($1);
> 	}
>     ' |
>     git hash-object -w -t commit --stdin
>   5a08c6b3f06d91c4a09c8d7ea6e9c8ce200b7698
>=20
> Now there's a parallel history of otherwise identical commits. I think
> this is mostly "if it hurts don't do it", but we generally try to avoid
> multiple representations of the same data within the object model.
>=20
> I think only commits and tags are subject to this (because the tree
> hashes are binary). I don't know if you'd be able to stumble into this
> accidentally with most Git commands. We don't intentionally normalize
> case anywhere, but I think most code will round-trip through a binary
> hash at some point (so "git commit-tree 1234ABCD" would incidentally
> normalize the case).

Yes, this is true.  I agree that multiple representations is a problem,
and although that can be an issue with signatures, we shouldn't make it
worse.

In addition, those objects cannot be round-tripped through the
interoperability code (which only writes lowercase object IDs), so
they're effectively locked to SHA-1 only.
--=20
brian m. carlson (they/them)
Toronto, Ontario, CA

--jTRfy0c7VV0awmXZ
Content-Type: application/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----

wr0EABYKAG8FgmpvvL4JEHwMSWKIh6KBRxQAAAAAAB4AIHNhbHRAbm90YXRpb25z
LnNlcXVvaWEtcGdwLm9yZ4MpjOkVEl6BWlDhOQqoq8xIsIhi3us9m3kFn6GfVHVI
FiEECCzmip28ZfuD0cORfAxJYoiHooEAABI4AP0RfOUb46eu+soNM2FmrOJQVQfg
usXdutMKGWR2AuofhwD9HxRA+lAC1fpxld709ezJO0tSO8LDWHNDTJGiF4kQqwI=
=chKs
-----END PGP SIGNATURE-----

--jTRfy0c7VV0awmXZ--