On Fri, 2008-09-12 at 17:54 +0200, Stephen R. van den Berg wrote: > Theodore Tso wrote: > >Nope, as Sam suggested in his original message (but which got clipped > >by Linus when he was replying) all you have to do is to have a > >separate local database which ties commits and patch-id's together as > >a cache/index. > > True. But repopulating this cache after cloning means that you have to > calculate the patch-id of *every* commit in the repository. It sounds > like something to avoid, but maybe I'm overly concerned, I have only a > vague idea on how computationally intensive this is. You don't necessarily need to do that. If the tool decides that the sha1 it finds in the message is a patch-id reference, well it can just start hunting around, caching the patch-ids it calculates as it finds them, until it either finds one that matches, or determines you don't have it. You can probably find it first try just based on the author name and date 90% of the time anyway. Maybe the machinery could be adequately tilted such that if someone is really desperate to make sure they are found quickly they can put the information at refs/patches/PATCHID/COMMITID, but that sounds a bit abusive. Sam. -- 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
