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

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