RE: [PATCH v2 1/1] unpack-trees: skip stat on fsmonitor-valid files

From: Kevin Willford <kevin.willford@microsoft.com>
Date: Nov 6, 2019, 17:24 UTC
Message-ID: <BN6PR21MB0786BC0CD7ABD6B3EEACE74B91790@BN6PR21MB0786.namprd21.prod.outlook.com>
In-Reply-To: <CAPYzU3PLVhGWcautao1oenbKbgcOB_99PoyVEcK1hnUk5XErKg@mail.gmail.com>

Show 8 quoted lines

> From: Utsav Shah <utsav@dropbox.com>
> 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;
}