Thread (11 messages) 11 messages, 3 authors, 2019-11-20

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;
}
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help