Re: [PATCH] unpack-trees: also allow get_progress() to work on a different index

Elijah Newren [off-list ref] writes:

On Thu, May 14, 2020 at 3:17 PM Junio C Hamano [off-list ref] wrote:

quoted

Elijah Newren [off-list ref] writes:

quoted

quoted

Do we see these CE_UPDATE|CE_WT_REMOVE bits attached to the cache
entries in the o->src_index array when get_progress() is fed the
src_index in the first place?

Yes, before calling check_updates(o, o->src_index), update_sparsity()
loops over o->src_index and calls apply_sparse_checkout() on each of
the non-conflicted cache entries.  apply_sparse_checkout() will set
either CE_UPDATE or CE_WT_REMOVE whenever items flip from or to having
the SKIP_WORKTREE bit set.

Hmph.

I thought that the whole point of splitting o->result from
o->src_index we did long time ago was to allow us to treat
o->src_index constant.  I hope we haven't broken anything by
starting to do things like that X-<.

I think we're safe there.  No function started modifying o->src_index
directly; they just modify the index they are passed in.  The only
place that passes o->src_index to functions for modification is
update_sparsity(), which unpack_trees() never calls.

OK.  Thanks for an additional detail.  Let's merge it down by -rc1.