Re: GSoC - Designing a faster index format

Got a few questions:

1. index is used for building next commit, so it should only include
files created/modified/deleted. But I see it has all entries for
current working dir. why?

2. From read_index_from() I see the whole index is read into mem, and
write one by one (entry/ext) back to disk. This makes sense. But why
we have to compute Sha1 for all entries, especially unchanged entries?

3. how does git track updated files? Does it compare the ts between
working dir and index ? Or they are recorded somewhere?

4. When does git insert to cache tree? and when it retrieve from it?

Some early thoughts for the tree format:

We can use B tree like format. Keep the header in the beginning of the file as is, but add file length (4bytes) and the pointer to extensions (8bytes) into header. Entry list follows the header. The entry starts with number of children offsets (1 byte) followed by list of offsets (4 bytes each). We can limit the number for balance. Other fields leave as is. Extensions can locate in between entries.

Use Sha1 , rather than the path, as the key for each entry node. This beats the case like 1000 files in a dir which breaks the balance of the tree, as Thomas mentioned. If a file is updated, the old Sha1 can be found in object dir. This also gives flexibility. We may use splay tree, in order to move updated nodes close to the root. The downside is full path has to be stored in entry.

Regards, Elton

On Wed, Mar 21, 2012 at 11:01 PM, elton sky <eltonsky9404@gmail.com> wrote: