git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Patrick Steinhardt <ps@pks.im>
Cc: git@vger.kernel.org,  Jeff King <peff@peff.net>,
	 Han Jiang <jhcarl0814@gmail.com>
Subject: Re: [PATCH 4/4] builtin/remote: only iterate through refs that are to be renamed
Date: Mon, 28 Jul 2025 10:43:43 -0700	[thread overview]
Message-ID: <xmqq7bzsw6r4.fsf@gitster.g> (raw)
In-Reply-To: <20250728-pks-remote-rename-improvements-v1-4-f654f2b5c5ae@pks.im> (Patrick Steinhardt's message of "Mon, 28 Jul 2025 15:08:48 +0200")

Patrick Steinhardt <ps@pks.im> writes:

> When renaming a remote we also need to rename all references
> accordingly. But while we only need to rename references that are
> contained in the "refs/remotes/$OLDNAME/" namespace, we end up using
> `refs_for_each_rawref()` that iterates through _all_ references. We know
> to exit early in the callback in case we see an irrelevant reference,
> but ultimately this is still a waste of compute as we knowingly iterate
> through references that we won't ever care about.

Very true.  Even if we guarantee that callbacks are fed references in
lexicographic order, that would only allow us to stop iterationg
when we see an irrelevant one", and still would force us to skip
over all the irrelevant ones until we see the first one in scope.

It makes perfect sense to give us a way to say "iterate only in this
subhierarchy" like this step does.

Nice.

  reply	other threads:[~2025-07-28 17:43 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-28 13:08 [PATCH 0/4] builtin/remote: rework how remote refs get renamed Patrick Steinhardt
2025-07-28 13:08 ` [PATCH 1/4] refs: pass refname when invoking reflog entry callback Patrick Steinhardt
2025-07-28 15:59   ` Justin Tobler
2025-07-28 16:07   ` Junio C Hamano
2025-07-29 20:30   ` Karthik Nayak
2025-07-31  8:28     ` Patrick Steinhardt
2025-07-28 13:08 ` [PATCH 2/4] refs: simplify logic when migrating reflog entries Patrick Steinhardt
2025-07-28 16:08   ` Justin Tobler
2025-07-28 16:21   ` Junio C Hamano
2025-07-28 13:08 ` [PATCH 3/4] builtin/remote: rework how remote refs get renamed Patrick Steinhardt
2025-07-28 17:19   ` Junio C Hamano
2025-07-29  8:43     ` Patrick Steinhardt
2025-07-28 18:47   ` Justin Tobler
2025-07-28 18:57     ` Junio C Hamano
2025-07-29  8:43       ` Patrick Steinhardt
2025-07-29  8:16   ` Jeff King
2025-07-29 12:24     ` Patrick Steinhardt
2025-08-02 10:48       ` Jeff King
2025-07-28 13:08 ` [PATCH 4/4] builtin/remote: only iterate through refs that are to be renamed Patrick Steinhardt
2025-07-28 17:43   ` Junio C Hamano [this message]
2025-07-30  7:53   ` Karthik Nayak
2025-07-31  8:28     ` Patrick Steinhardt
2025-07-28 15:43 ` [PATCH 0/4] builtin/remote: rework how remote refs get renamed Junio C Hamano
2025-07-31 14:56 ` [PATCH v2 0/6] " Patrick Steinhardt
2025-07-31 14:56   ` [PATCH v2 1/6] refs: pass refname when invoking reflog entry callback Patrick Steinhardt
2025-07-31 14:56   ` [PATCH v2 2/6] refs: simplify logic when migrating reflog entries Patrick Steinhardt
2025-07-31 14:56   ` [PATCH v2 3/6] builtin/remote: fix sign comparison warnings Patrick Steinhardt
2025-07-31 14:56   ` [PATCH v2 4/6] builtin/remote: determine whether refs need renaming early on Patrick Steinhardt
2025-07-31 14:56   ` [PATCH v2 5/6] builtin/remote: rework how remote refs get renamed Patrick Steinhardt
2025-08-02 10:45     ` Jeff King
2025-08-04  6:54       ` Patrick Steinhardt
2025-07-31 14:56   ` [PATCH v2 6/6] builtin/remote: only iterate through refs that are to be renamed Patrick Steinhardt
2025-07-31 19:15   ` [PATCH v2 0/6] builtin/remote: rework how remote refs get renamed Junio C Hamano
2025-08-01  4:59     ` Patrick Steinhardt
2025-08-01 16:43       ` Junio C Hamano
2025-08-04  6:51         ` Patrick Steinhardt
2025-08-04 18:24           ` 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

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

  git send-email \
    --in-reply-to=xmqq7bzsw6r4.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=jhcarl0814@gmail.com \
    --cc=peff@peff.net \
    --cc=ps@pks.im \
    /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 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 NNTP newsgroup(s).