RE: [PATCH v2 1/1] unpack-trees: skip stat on fsmonitor-valid files
From: Kevin Willford <hidden>
Date: 2019-11-06 17:24:43
From: Utsav Shah <redacted> Sent: Tuesday, November 5, 2019 9:36 PM The one part that I don't fully understand if safe is copying over the o->src_index->fsmonitor_last_update to the result index in unpack-trees. I don't understand the implications of that, and if that's the only field worth copying over, or if we should be copying over other fields like the bitmap as well.
The data from the bitmap has already been applied to the index entries at
this point so it is no longer needed after that.
fsmonitor_last_update is really just being used as the flag to fill the bitmap
and write out the fsmonitor extension. The fill_fsmonitor_bitmap will use
the current CE_FSMONITOR_VALID flags for the index entries to create the
bitmap.
if (istate->fsmonitor_last_update)
fill_fsmonitor_bitmap(istate);
void fill_fsmonitor_bitmap(struct index_state *istate)
{
unsigned int i, skipped = 0;
istate->fsmonitor_dirty = ewah_new();
for (i = 0; i < istate->cache_nr; i++) {
if (istate->cache[i]->ce_flags & CE_REMOVE)
skipped++;
else if (!(istate->cache[i]->ce_flags & CE_FSMONITOR_VALID))
ewah_set(istate->fsmonitor_dirty, i - skipped);
}
}
if (!strip_extensions && istate->fsmonitor_last_update) {
struct strbuf sb = STRBUF_INIT;
write_fsmonitor_extension(&sb, istate);
err = write_index_ext_header(&c, &eoie_c, newfd, CACHE_EXT_FSMONITOR, sb.len) < 0
|| ce_write(&c, newfd, sb.buf, sb.len) < 0;
strbuf_release(&sb);
if (err)
return -1;
}