On 11 Sep 2006 10:26:44 -0400, linux@xxxxxxxxxxx <linux@xxxxxxxxxxx> wrote:
> 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@xxxxxxxxx - 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