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

From: Junio C Hamano <gitster@pobox.com>
Date: May 14, 2020, 22:16 UTC
Message-ID: <xmqqimgyp3ft.fsf@gitster.c.googlers.com>
In-Reply-To: <CABPp-BHM8uS1yxAtjE=Frh_V7JF7-EJ8+47e-cr9TpEMZr4nfw@mail.gmail.com>

Elijah Newren <newren@gmail.com> writes:

Show 9 quoted lines

>> 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-<.

Anyway, if that is the case, this change won't make things any worse. Let's queue it.

Thanks.