Re: Change set based shallow clone

From: Jon Smirl <jonsmirl@gmail.com>
Date: Sep 11, 2006, 15:01 UTC
Message-ID: <9e4733910609110801p19ab39q5ef62bb60b89abb5@mail.gmail.com>
In-Reply-To: <20060911142644.32313.qmail@science.horizon.com>

On 11 Sep 2006 10:26:44 -0400, linux@horizon.com <linux@horizon.com> wrote:

Show 12 quoted lines

> > Could we do a cache of the refs that stores the stat information for
> > each of the files under .git/refs plus the sha1 that the ref points
> > to?  In other words this cache would do for the refs what the index
> > does for the working directory.  Reading all the refs would mean we
> > still had to stat each of the files, but that's much quicker than
> > reading them in the cold-cache case.  In the common case when most of
> > the stat information matches, we don't have to read the file because
> > we have the sha1 that the file contains right there in the cache.
>
> Well, that could save one of two seeks, but that's not *much* quicker.
> (Indeed, a git ref would fit into the 60 bytes of block pointer space
> in an ext2/3 inode if regular files were stuffed there as well as symlinks.)

Does everyone hate my idea of putting the sha in the file name and using the directory structure as a simple database with locking? No one made any comments.

------------------------------------------------ Here's a hack, instead of of putting the sha inside the file, put the sha into the filename.

master_86a8534ba23a5532f6d0ddd01ecd8f02f662cf78

Now you can just do a directory listing and get all of the data quickly. To keep the existing porcelain working add a symlink.

ln -s master_86a8534ba23a5532f6d0ddd01ecd8f02f662cf78 master

You might want the sha1 encoded names in a new director

-- 
Jon Smirl
jonsmirl@gmail.com