Re: [PATCH/RFC v2] read-cache: save index entry updates in ILOG index extension

[Duy Nguyen <pclouds@gmail.com>]

On Fri, Aug 9, 2013 at 1:46 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Nguyễn Thái Ngọc Duy  <pclouds@gmail.com> writes:
>
>> Old operation's updates are removed as new ones are added to keep the
>> size under 1 MB. ILOG keeps minimum 10 operations regardless of its
>> size. These contansts should be configurable later one. ILOG content
>> will be compressed later on so that it leaves minimum
>> footprint.
>
> List of <sha-1, pathname> tuples would not compress well, I suspect.

I was hoping that it still compresses well the discrete segments of
pathname. In the worst case we can group sha-1 together, separate from
pathnames.

>> Because it's only needed at index writing time, read-only
>> operations won't pay the cost for decompressing and compressing ILOG.
>
> Another idea is to lazily read existing ILOG by (1) keeping just an
> offset in the originating index file at read_index() time and (2)
> reading it on demand when ":-4:Makefile" was asked for.

We need to go through ILOG extension anyway for index sha-1
verification, so it's already read in kernel buffer. What we save is a
just malloc. But I'll try.

>
>> diff --git a/cache.h b/cache.h
>> index 85b544f..a2156bf 100644
>> --- a/cache.h
>> +++ b/cache.h
>> @@ -168,6 +168,7 @@ struct cache_entry {
>>
>>  /* used to temporarily mark paths matched by pathspecs */
>>  #define CE_MATCHED           (1 << 26)
>> +#define CE_BASE              (1 << 27)
>
> As this is not about pathspec match, please have its own comment
> line (or a blank line, if this goes without comment) above this new
> line.

This patch is more about the idea, whether it makes sense. You would
(and did) find the patch somewhat disgusting later on.

>> @@ -277,6 +278,7 @@ struct index_state {
>>                initialized : 1;
>>       struct hash_table name_hash;
>>       struct hash_table dir_hash;
>> +     struct strbuf *index_log;
>>  };
>
> Sane to have this as a per-index_state variable.
>
>> +extern void log_index_changes(const char *prefix, const char **argv);
>
> Not sane to name this function _index_anything and not to have index_state
> as its first parameter, breaking the naming convention.

The reason I can't put index_state there is because this function is
called early, often before read_cache is is called. And I can't caller
it later because argv would be ruined by parse_options(). An option is
to convert argv to a string unconditionally in git.c, then
log_index_changes can be called much later, and with index_state
pointer.

>> +static void get_updated_entries(struct index_state *istate,
>> +                             struct cache_entry ***cache_out,
>> +                             unsigned int *cache_nr_out)
>> +{
>> +     struct cache_entry **cache;
>> +     unsigned int i, nr, cache_nr = 0;
>> +
>> +     *cache_nr_out = 0;
>> +     *cache_out = NULL;
>> +     for (i = 0; i < istate->cache_nr; i++) {
>> +             if (istate->cache[i]->ce_flags & CE_BASE)
>> +                     continue;
>> +             cache_nr++;
>> +     }
>> +     if (!cache_nr)
>> +             return;
>> +     cache = xmalloc(cache_nr * sizeof(*istate->cache));
>> +     for (i = nr = 0; i < istate->cache_nr; i++) {
>> +             struct cache_entry *ce = istate->cache[i];
>> +             if (ce->ce_flags & CE_BASE)
>> +                     continue;
>> +             cache[nr++] = ce;
>> +     }
>> +     *cache_out = cache;
>> +     *cache_nr_out = cache_nr;
>> +}
>
> I can read what the function does, but I do not understand the
> assumption this code makes.
>
> Is this assuming that any newly created cache_entry that goes to
> the_index via add_index_entry() will not have CE_BASE bit set?  Some
> codepaths try to preserve the flags bit they do not care and/or
> understand (e.g. rename_index_entry_at() creates a new ce with a new
> name, and keeps most of the flags bit except for the name-hash state
> bits), so CE_BASE will be propagated from the original to the new
> one, I think.
>
> You seem to be recording the state _after_ the change---that can be
> read without the extension, can't it?  I thought we care more about
> the state that was _lost_ by the change.
>
> Recording the state after the change misses deleted entries, doesn't
> it?

Right. At the end of the commit message I mentioned about "git add
--undo". After I wrote it, I became more convinced it's the way to go.
That should be the UI, instead of letting the user hunt the right
entry through the index log. And then caller has the responsibility to
track changes and feed it to read-cache (CE_BASE trick is gone). And
it would record something like raw diff: a pair of old/new sha-1 and a
path name. This helps differentiate modified, deleted and added
entries that "git add --undo" may need to undo.

>> +static void write_index_log(struct strbuf *sb,
>> +                         const struct strbuf *old_log,
>> +                         const struct strbuf *msg,
>> +                         struct cache_entry **cache,
>> +                         unsigned int cache_nr)
>> +{
>> +     struct strbuf body = STRBUF_INIT;
>> +     unsigned int i, size, nr, body_len, hdr_len;
>> +     const char *end, *p;
>> +     strbuf_addf(&body, "%s%c", msg->buf, '\0');
>> +     for (i = 0; i < cache_nr; i++)
>> +             strbuf_addf(&body, "%s %s%c", sha1_to_hex(cache[i]->sha1),
>> +                         cache[i]->name, '\0');
>
> We do not care about file modes (e.g. "update-index --chmod")?

Not as valuable in my opinion. But if I implement "git add --undo", I
probably need to pay attention to file modes or some users may get
upset as it's not a "real undo" otherwise.
-- 
Duy