On Fri, Sep 12, 2008 at 05:40:26PM +0200, Paolo Bonzini wrote: > > But it is not true that "you can always generate the cache from the > > git repository" in this case; the patch-id that is to be saved is > > _original_ patch-id of cherry-picked (or reverted) changeset. > > He's proposing storing the original patch id in the commit message, and > caching the commit SHA->patch id association on the side. > Actually its the association in the other direction which you'd want to cache. It's fast given the commit SHA to dig the original patch id out of the commit message. What is harder is given a patch id X, to find all of the commits which either (a) have a patch id of X, or (b) have a commit message indicating that the original patch-id was X. So having a database which caches this information, so given a patch-id, you can quickly look up the related commits, is what I believe Sam was proposing, and which I think would solve the problem quite nicely. - Ted -- 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
