git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "Elijah Newren via GitGitGadget" <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org, jeffhost@microsoft.com,
	Elijah Newren <newren@gmail.com>
Subject: Re: [PATCH] unpack-trees: also allow get_progress() to work on a different index
Date: Thu, 14 May 2020 13:22:12 -0700	[thread overview]
Message-ID: <xmqq4ksiqnbf.fsf@gitster.c.googlers.com> (raw)
In-Reply-To: <pull.785.git.git.1589486002453.gitgitgadget@gmail.com> (Elijah Newren via GitGitGadget's message of "Thu, 14 May 2020 19:53:22 +0000")

"Elijah Newren via GitGitGadget" <gitgitgadget@gmail.com> writes:

> From: Elijah Newren <newren@gmail.com>
>
> 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@microsoft.com>
> Signed-off-by: Elijah Newren <newren@gmail.com>
> ---
>     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.

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?  

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?

>
> Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-785%2Fnewren%2Frecent-sparse-checkout-bugfix-v1
> Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-785/newren/recent-sparse-checkout-bugfix-v1
> Pull-Request: https://github.com/git/git/pull/785
>
>  unpack-trees.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/unpack-trees.c b/unpack-trees.c
> index 1fe3764f2b2..2e6e9d5eeb8 100644
> --- a/unpack-trees.c
> +++ b/unpack-trees.c
> @@ -333,10 +333,10 @@ static void load_gitmodules_file(struct index_state *index,
>  	}
>  }
>  
> -static struct progress *get_progress(struct unpack_trees_options *o)
> +static struct progress *get_progress(struct unpack_trees_options *o,
> +				     struct index_state *index)
>  {
>  	unsigned cnt = 0, total = 0;
> -	struct index_state *index = &o->result;
>  
>  	if (!o->update || !o->verbose_update)
>  		return NULL;
> @@ -415,7 +415,7 @@ static int check_updates(struct unpack_trees_options *o,
>  	if (o->clone)
>  		setup_collided_checkout_detection(&state, index);
>  
> -	progress = get_progress(o);
> +	progress = get_progress(o, index);
>  
>  	git_attr_set_direction(GIT_ATTR_CHECKOUT);
>  
>
> base-commit: b994622632154fc3b17fb40a38819ad954a5fb88

  reply	other threads:[~2020-05-14 20:22 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 [this message]
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

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

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=xmqq4ksiqnbf.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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).