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

On Thu, Jul 30, 2026 at 09:18:40PM +0000, brian m. carlson wrote:

The situation is presently that Git will accept them and this leads to
surprising behaviour, but almost all adjacent software rejects or
mishandles them.  I'm arguing that we should stop accepting hex object
ID formats that cannot be effectively used in the Git ecosystem but
whose presence is effectively only ever the source of misbehaviour and
security vulnerabilities.

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).

-Peff