Re: [RFC PATCH 6/6] hex: allow only lowercase object IDs in breaking changes mode

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 31, 2026, 12:33 UTC
Message-ID: <xmqqtspffidw.fsf@gitster.g>
In-Reply-To: <xmqqv79vha69.fsf@gitster.g>

Junio C Hamano <gitster@pobox.com> writes:

Show 8 quoted lines

> "brian m. carlson" <sandals@crustytoothpaste.net> writes:
>
>> Git has historically allowed either lowercase or uppercase hex for
>> object IDs, but it has always emitted only lowercase.  This has caused
>> people to expect only lowercase and not handle uppercase.
>
> It is violation of Postel's Law by other people.  We do not
> necessarily have to follow suit.

Imagine we somehow misbehave badly when we have two loose object files storing the same object's contents. Let us further imagine that we can download these individual loose object files from others, perhaps via the dumb HTTP transport.

If we tried to be robust, we would be liberal in what we accept, even though we try to be strict in what we produce. In this hypothetical scenario, if we talk to someone else over the dumb HTTP transport and find that they have an objects/AB/ directory, we may try to be liberal and say, "Ah, that is a fan-out directory housing all their loose objects whose names begin with 'ab'."

This is the right thing to do for those who liberally accept others' data.

But we might further say, "Let us enumerate and download what we do not have locally. They have a file 012345...EF (38 hex characters) in that directory, which stores the object AB012345...EF (40 hex characters) in loose object form," and then conclude, "and we do not have it," even when we actually have the file ab/012345...ef in all-lowercase form locally!

However, liberally accepting AB/012345...EF and storing it verbatim in our own store will break things because, in this hypothetical scenario, we will misbehave when we have both ab/012345...ef (which we had from the start) and AB/012345...EF (which we just downloaded) at the same time.

The approach taken by this RFC series is to stop recognizing their objects/AB/ as a valid fan-out directory and their AB/012345...EF as a valid loose object file. While I agree that this is certainly one way to avoid entering such a state and triggering bad behavior, I think the real solution that honors the robustness principle is to still recognize objects/AB/012345...EF as valid, recognize it as a loose object file for ab012345...ef, and notice that it represents the same object ab012345...ef we already have. Then we can avoid misbehaving without being less liberal than we used to be.

If the system had been case-sensitive from day one, and ignoring uppercase hex had been the norm from the beginning, I would not have found it so disturbing that we reject case-insensitive object names and being stricter than folks with those other systems may feel is necessary.

Tightening the rule after twenty years is the part I am most hesitant to accept. So, I dunno.