brian m. carlson writes ("Re: Transition plan for git to move to a new hash function"):
> On Mon, Feb 27, 2017 at 01:00:01PM +0000, Ian Jackson wrote:
> > Objects of one hash may refer to objects named by a different hash
> > function to their own. Preference rules arrange that normally, new
> > hash objects refer to other new hash objects.
>
> The existing codebase isn't really intended with that in mind.
Yes. I've seen the attempts to start to replace char* with a hash
struct.
> I like Peff's suggested approach in which we essentially rewrite history
> under the hood, but have a lookup table which looks up the old hash
> based on the new hash. That allows us to refer to old objects, but not
> have to share serialized data that mentions both hashes.
I think this means that the when a project converts, every copy of the
history must be rewritten (separately). Also, this leaves the whole
system lacking in algorithm agililty. Meaning we may have to do all
of this again some time.
I also think that we need to distinguish old hashes from new hashes in
the command line interface etc. Otherwise there is a possible
ambiguity.
> > The object name textual syntax is extended. The new syntax may be
> > used in all textual git objects and protocols (commits, tags, command
> > lines, etc.).
> >
> > We declare that the object name syntax is henceforth
> > [A-Z]+[0-9a-z]+ | [0-9a-f]+
> > and that names [A-Z].* are deprecated as ref name components.
>
> I'd simply say that we have data always be in the new format if it's
> available, and tag the old SHA-1 versions instead. Otherwise, as Peff
> pointed out, we're going to be stuck typing a bunch of identical stuff
> every time. Again, this encourages migration.
The hash identifier is only one character. Object names are not
normally typed very much anyway.
If you say we must decorate old hashes, then all existing data
everywhere in the world which refers to any git objects by object name
will become invalid. I don't mean just data in git here. I mean CI
systems, mailing list archives, commit messages (perhaps in other
version control systems), test cases, and so on.
Ian.