From: Patrick Steinhardt <ps@pks.im>
To: Jeff King <peff@peff.net>
Cc: Han Jiang <jhcarl0814@gmail.com>, Git Mailing List <git@vger.kernel.org>
Subject: Re: `git remote rename` does not work when `refs/remotes/server/HEAD` is unborn (when right after `git remote add -m`)
Date: Mon, 28 Jul 2025 08:05:20 +0200 [thread overview]
Message-ID: <aIcTIFbKud0k2ioB@pks.im> (raw)
In-Reply-To: <20250725110243.GA3014187@coredump.intra.peff.net>
On Fri, Jul 25, 2025 at 07:02:43AM -0400, Jeff King wrote:
> On Thu, Jul 24, 2025 at 03:03:27PM +0200, Patrick Steinhardt wrote:
>
> > I've quickly hacked something together now, see the work-in-progress
> > patch below. The patch does not yet handle reflogs, but that isn't too
> > hard to implement.
> >
> > And these changes indeed speed up things by quite a lot: instead of
> > hours it now takes 7 seconds :) I'll polish this patch series and will
> > likely send it in tomorrow.
>
> Cool. I agree with all of the pain points you outlined, and the general
> direction. There was one other sub-optimal thing I noticed, which was...
>
> > - refs_for_each_ref(get_main_ref_store(the_repository),
> > - read_remote_branches, &rename);
> > [...]
> > + result = refs_for_each_rawref(get_main_ref_store(the_repository),
> > + queue_one_rename, &rename);
>
> Both before and after your patch, we're iterating over _all_ refs and
> skipping ones that aren't in "refs/remotes/<remote>/". If we just ask to
> iterate over that subset of refs, then we save the effort of iterating
> over the others that we don't care about.
>
> But:
>
> 1. We have refs_for_each_ref_in() and refs_for_each_rawref(), but no
> refs_for_each_rawref_in(). Feels like it should be easy to add it,
> though.
>
> 2. It's an obvious small optimization, but it doesn't help us in a
> big-O way. Iterating the refs is obviously O(n), and in the worst
> case rewriting the packed-refs file is likewise O(n). So I wouldn't
> expect to see the dramatic improvements you found by removing the
> quadratic bits. But I'd bet it's still measurable in a repo with a
> lot of refs (and maybe with reftables it actually would be bigger,
> since the goal there is to amortize the rewrites).
Yeah, I was wondering whether to re-do this part while at it. I
initially decided to not do so, but I guess that was just me being lazy.
Patrick
prev parent reply other threads:[~2025-07-28 6:05 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-24 9:59 `git remote rename` does not work when `refs/remotes/server/HEAD` is unborn (when right after `git remote add -m`) Han Jiang
2025-07-24 10:45 ` Jeff King
2025-07-24 11:58 ` Patrick Steinhardt
2025-07-24 13:03 ` Patrick Steinhardt
2025-07-24 18:38 ` Junio C Hamano
2025-07-25 8:00 ` Patrick Steinhardt
2025-07-25 11:02 ` Jeff King
2025-07-25 11:13 ` Jeff King
2025-07-28 6:05 ` Patrick Steinhardt
2025-07-28 6:05 ` Patrick Steinhardt [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=aIcTIFbKud0k2ioB@pks.im \
--to=ps@pks.im \
--cc=git@vger.kernel.org \
--cc=jhcarl0814@gmail.com \
--cc=peff@peff.net \
/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).