From: Jeff King <peff@peff.net>
Date: Sat, 01 Aug 2026 14:45:27 GMT
Subject: Re: [RFC PATCH 0/6] Git 3.0: restrict hex object IDs to lowercase only
Message-ID: <20260801144527.GF2041176@coredump.intra.peff.net>
In-Reply-To: <amu_rzanuYc_2lww@fruit.crustytoothpaste.net>

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