All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Elijah Newren <newren@gmail.com>
Cc: Elijah Newren via GitGitGadget <gitgitgadget@gmail.com>,
	Git Mailing List <git@vger.kernel.org>,
	Jeff Hostetler <jeffhost@microsoft.com>
Subject: Re: [PATCH] unpack-trees: also allow get_progress() to work on a different index
Date: Fri, 15 May 2020 08:01:10 -0700	[thread overview]
Message-ID: <xmqq8shtnsy1.fsf@gitster.c.googlers.com> (raw)
In-Reply-To: <CABPp-BFAR=+CxwcZz1v4n3Z53uEas5P6Y7pUT7u9dAL0hULe3w@mail.gmail.com> (Elijah Newren's message of "Thu, 14 May 2020 16:21:14 -0700")

Elijah Newren <newren@gmail.com> writes:

> On Thu, May 14, 2020 at 3:17 PM Junio C Hamano <gitster@pobox.com> wrote:
>>
>> Elijah Newren <newren@gmail.com> writes:
>>
>> >> 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.


      reply	other threads:[~2020-05-15 15:01 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-14 19:53 [PATCH] unpack-trees: also allow get_progress() to work on a different index Elijah Newren via GitGitGadget
2020-05-14 20:22 ` Junio C Hamano
2020-05-14 21:46   ` Elijah Newren
2020-05-14 22:16     ` Junio C Hamano
2020-05-14 23:21       ` Elijah Newren
2020-05-15 15:01         ` Junio C Hamano [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqq8shtnsy1.fsf@gitster.c.googlers.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=jeffhost@microsoft.com \
    --cc=newren@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.