Re: RFC: Another proposed hash function transition plan
- Date: Tue, 7 Mar 2017 09:03:15 +0900
- From: Mike Hommey <mh@xxxxxxxxxxxx>
- Subject: Re: RFC: Another proposed hash function transition plan
On Mon, Mar 06, 2017 at 03:40:30PM -0800, Jonathan Nieder wrote:
> David Lang wrote:
> >> Translation table
> >> ~~~~~~~~~~~~~~~~~
> >> A fast bidirectional mapping between sha1-names and sha256-names of
> >> all local objects in the repository is kept on disk. The exact format
> >> of that mapping is to be determined.
> >> All operations that make new objects (e.g., "git commit") add the new
> >> objects to the translation table.
> > This seems like a rather nontrival thing to design. It will need to
> > hold millions of mappings, and be quickly searchable from either
> > direction (sha1->new and new->sha1) while still be fairly fast to
> > insert new records into.
> I am currently thinking of using LevelDB, since it has the advantages of
> being simple, already existing, and having already been ported to Java
> (allowing JGit can read and write the same format).
> If that doesn't work, we'd try some other key-value store like Samba's
> tdb or Kyoto Cabinet.
FWIW, I'm using notes-like data to store mercurial->git mappings in
git-cinnabar, (ab)using the commit type in tree items. It's fast enough.