All of lore.kernel.org
 help / color / mirror / Atom feed
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

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