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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, May 14, 2020 at 1:22 PM Junio C Hamano <gitster@xxxxxxxxx> wrote:
>
> "Elijah Newren via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes:
>
> > From: Elijah Newren <newren@xxxxxxxxx>
> >
> > commit b0a5a12a60 ("unpack-trees: allow check_updates() to work on a
> > different index", 2020-03-27) allowed check_updates() to work on a
> > different index, but it called get_progress() which was hardcoded to
> > work on o->result much like check_updates() had been.  Update it to also
> > accept an index parameter and have check_updates() pass that parameter
> > along so that both are working on the same index.
> >
> > Noticed-by: Jeff Hostetler <jeffhost@xxxxxxxxxxxxx>
> > Signed-off-by: Elijah Newren <newren@xxxxxxxxx>
> > ---
> >     unpack-trees: also allow get_progress() to work on a different index
> >
> >     This is a fix to a minor 2.27 regression, from the en/sparse-checkout
> >     series.
>
> OK, so update_sparsity() calls the function with o->src_index,
> get_progress() without this fix would iterate over an unrelated
> o->result to count the cache entries that are marked for update or
> removal and show the progress based on that number without this
> patch?  The other caller in unpack_trees() uses o->result so there
> is no change in the behaviour with or without the patch.

Yes.

> The flag bits on cache entries used to count the entries in the
> index by the get_progress() function are applied only on the
> o->result side when merged_entry() and friends call do_add_entry(),
> no?

Not quite; unpack_trees() also calls apply_sparse_checkout(), passing
it o->result, and apply_sparse_checkout() also sets those bits.

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



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux