Re: Index/hash order

Ingo Molnar wrote:

with a plaintext repository we could do the 'hardlink trick' (which 
brings in other manageability problems and limitations but is at least a 
partially good idea), which would make the working tree and the 
repository share the same inode in most cases.

While in the compressed case we'd have a separate compressed inode 
(taking up RAM with all its contents) and the working directory inode 
(taking up RAM) - summing up to more RAM than if we only had a single 
inode per object.

furthermore, when generating/destroying large trees (which is a quite 
common thing), a hardlinked solution is faster, as it doesnt create 
250MB+ of dirty RAM. In some cases (e.g. handling dozens of 'merge 
trees') it's dramatically faster.

You could still have the hardlink way by way of a .git/cache that keeps 
uncompressed files, keep the files with their hash names but uncompressed.

It will be easy to find, fully hard-linkable, only keep the needed files 
  uncompressed and the three year old file compressed. The

You can even save some CPU time by checking if the file is in the cache 
before decompressing it, though it does cost you with an extra disk 
access to see if it's there or not. If you repeat the operation enough 
you'll have the uncompressed version in the cache most of the times anyway.

Clear the cache weekly or so to avoid stale files from an ancient version.

Baruch