Re: Change set based shallow clone

From: Shawn Pearce <spearce@spearce.org>
Date: Sep 11, 2006, 00:03 UTC
Message-ID: <20060911000306.GA28927@spearce.org>
In-Reply-To: <17668.2019.732961.855446@cargo.ozlabs.ibm.com>

Paul Mackerras <paulus@samba.org> wrote: [snip]

Show 6 quoted lines

> The bottom line is that I can speed up the startup for the hot-cache
> case quite a lot.  The cold-cache case is going to take about 20-30
> seconds whatever I do unless Linus or Junio can come up with a way to
> pack the heads and tags.  I could read the refs asynchronously but
> there will still be a long delay in git rev-parse if you give
> arguments such as --all.

I've been thinking about implementing ref storage within a Git tree object. Just store the commit/tag/object IDs in a tree (or graph of trees) with a mode of '0'. Anchor that under '.git/refs-tree'. Any edit of a ref would "lock" .git/refs-tree, create a new tree containing the update, then replace .git/refs-tree.

But it would put additional stress on the objects directory by creating a lot of trees which would never get pulled into pack files and thus would need to be pruned away on a regular basis.

It also would make parallel updates more difficult on the server side as everyone would need to wait for the lock to .git/refs-tree before they can change any ref; today users only need to wait for the ref they are trying to change.

It also doesn't help looking up a ref quickly; although trees are sorted they are variable length entries which forces the application to read the entire tree to find its entry.

Given those three downsides I haven't put anything to code yet.

-- 
Shawn.