From: brian m. carlson <sandals@crustytoothpaste.net>
Date: Sun, 02 Aug 2026 21:55:10 GMT
Subject: Re: [RFC PATCH 0/6] Git 3.0: restrict hex object IDs to lowercase only
Message-ID: <am-8vm5QwLQhiXaO@fruit.crustytoothpaste.net>
In-Reply-To: <20260801144527.GF2041176@coredump.intra.peff.net>

On 2026-08-01 at 14:45:27, Jeff King wrote:
> Another interesting case is upper-case hex within objects:
> 
>   $ git rev-parse HEAD
>   b85b9595a8136c79551340c3d73443a62eddd893
> 
>   $ git cat-file commit HEAD |
>     perl -lpe '
>         if (/^parent (.*)/) {
> 		$_ = "parent " . uc($1);
> 	}
>     ' |
>     git hash-object -w -t commit --stdin
>   5a08c6b3f06d91c4a09c8d7ea6e9c8ce200b7698
> 
> 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.
> 
> 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.
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA