On Thu, May 29, 2008 at 10:13 AM, Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote: > Hi, > > On Thu, 29 May 2008, Geoffrey Irving wrote: > >> I'm planning to use cherry picking to manage long term syncing between >> cvs/perforce and git repositories. This means I'll have scripts running >> git-cherry between branches with hundreds of uncommon commits, and I >> want git-cherry to be much, much, faster. >> >> It looks like I can do this by caching commit->patch-id pairs from >> commit_patch_id() in patch-ids.c to a file, say >> $GIT_DIR/commit-patch-id-cache. The file would be binary and append >> only, and could be blown away if . Any suggestions / concerns before >> I write this? Is there any reusable efficient map code for storing >> the commit->patch-id map, or should I just mirror the blocked storage >> + binary search used for struct patch_ids? > > I would store the stuff sorted, so that the lookup is fast, generation > less so. The motivation for append-only was robustness, not speed, but I don't think either concern is very significant. > For inspiration, you might want to look at the "notes" branch in my > personal fork: > > http://repo.or.cz/w/git/dscho.git?a=shortlog;h=refs/heads/notes Cool. I'd rather copy just that code entirely rather than use it for inspiration, since it does exactly what I need. It would be silly to have two blocks of code implementing "persistent map from 20 byte hash to 20 byte hash". I'll start by just copying the entire nodes-index implementation (with a few name substitutions), and we (or I) can refactor it later if both end up in the same respository. Geoffrey -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
