Junio C Hamano writes ("Re: SHA1 collisions found"):
> Ian Jackson <ijackson@xxxxxxxxxxxxxxxxxxxxxx> writes:
> > * Therefore the transition needs to be done by giving every object
> > two names (old and new hash function). Objects may refer to each
> > other by either name, but must pick one. The usual shape of
>
> I do not think it is necessrily so.
Indeed. And my latest thoughts involve instead having two parallel
systems of old and new objects.
> *1* In the above toy example, length being 40 vs 64 is used as a
> sign between SHA-1 and the new hash, and careful readers may
> wonder if we should use sha-3,20769079d22... or something like
> that that more explicity identifies what hash is used, so that
> we can pick a hash whose length is 64 when we transition again.
I have an idea for this. I think we should prefix new hashes with a
single uppercase letter, probably H.
Uppercase because: case-only-distinguished ref names are already
discouraged because they do not work properly on case-insensitive
filesystems; convention is that ref names are lowercase; so an
uppercase letter probably won't appear at the start of a ref name
component even though almost all existing software will treat it as
legal. So the result is that the new object names are unlikely to
collide with ref names.
(There is of course no need to store the H as a literal in filenames,
so the case-insensitive filesystem problem does not apply to ref
names.)
We should definitely not introduce new punctuation into object names.
That will cause a great deal of grief for existing software which has
to handle git object names and may thy to store them in
representations which assume that they match \w+.
The idea of using the length is a neat trick, but it cannot support
the dcurrent object name abbreviation approach unworkable.
Ian.