Re: [PATCH 17/32] read-cache: split-index mode

> Nguyễn Thái Ngọc Duy  <pclouds@gmail.com> writes:
>
>> diff --git a/cache.h b/cache.h
>> index 0f6247c..90a5998 100644
>> --- a/cache.h
>> +++ b/cache.h
>> @@ -135,6 +135,7 @@ struct cache_entry {
>>       unsigned int ce_mode;
>>       unsigned int ce_flags;
>>       unsigned int ce_namelen;
>> +     unsigned int index;     /* for link extension */
>>       unsigned char sha1[20];
>>       char name[FLEX_ARRAY]; /* more */
>>  };
>
> I am not sure if we want to keep an otherwise unused 8-byte around
> per cache entry (especially for a large project where the split
> index mode should matter) after we read the index.
>
> I expected to see some code where entries in this incremental index
> are used to override the entries from the base/shared index, but
> merge_base_index() seems to do just memcpy() to discard the former
> and replace them with the latter.  Is this step meant to work at
> all, or is it a smaller step meant to be completed in later patches?

> I do think it is sensible to keep two arrays of "struct cache_entry"
> around (one for base and one for incremental changes) inside
> index_state, and the patch seems to do so via "struct split_index"
> that does have a copy of saved_cache.  If the write-out codepath
> walks these two sorted arrays in parallel, shouldn't it be able to
> figure out which entry is added, deleted and modified without
> fattening this structure?