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

[Junio C Hamano <gitster@pobox.com>]

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.

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