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

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 1, 2026, 18:22 UTC
Message-ID: <xmqqfr0x8zuu.fsf@gitster.g>
In-Reply-To: <20260801144527.GF2041176@coredump.intra.peff.net>

Jeff King <peff@peff.net> writes:

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

True. Already almost an empty rebase that delays the clock by 1 seconds is a perfectly normal thing, and the way we treat such a parallel history with the original would be the same as such an uppercase parallel history, so I do not think it is a huge issue.

A tree object hierarchy consists fully of binary links, so we are OK. Only the top-level object name within a commit/tag may have multiple representation of the same tree objects.

'git diff COMMIT-A COMMIT-B' would notice that they record the same tree without opening two tree objects, even if these two commits record a normal tree and uppercase equivalent tree, as diff_tree() layer will be called with the binary representation of the tree object names.

As Brian alluded to in his discussion starter message, we normalize the case by going binary in many places (we cannot unfortunately say "in strategic places"), and these are such cases.

Show 6 quoted lines

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