On Fri, Sep 12, 2008 at 06:43:48PM +0200, Stephen R. van den Berg wrote:
quoted text
> >> 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.
> 
> >For a rough estimate, try:
> 
> >  time git log -p | git patch-id >/dev/null
> 
> On my system that results in 2ms per commit on average.  Not huge, but
> not small either, I guess.  Running it results in real waiting time, it
> all depends on how patient the user is.

For a local clone, git could be taught to copy the cache file.  For a
network-based clone, the percentage of time needed to download is
roughly 2-3 times that (although that will obviously depend on your
network connectivity).  Building this cache can be done in the
background, though, or delayed until the first time the cache is
needed.

						- Ted
--
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