On Tue, Apr 29, 2014 at 5:46 AM, Junio C Hamano <gits...@pobox.com> wrote:
> Nguyễn Thái Ngọc Duy  <pclo...@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?

This field only matters at write time, not read time. It's to quickly
detect if an entry is shared, see prepare_to_write_split_index().

> 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?

So far without that "index" field I would have to resort to hasing
entries in both arrays to find the shared paths. But ideas are
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to