On Fri, 2008-09-12 at 17:54 +0200, Stephen R. van den Berg wrote:
quoted text
> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html