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

Junio C Hamano <[email protected]> writes:

> "brian m. carlson" <[email protected]> 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.