Re: [RFC PATCH 0/2] fetch --prune performance problem

From: Jeff King <peff@peff.net>
Date: Jun 19, 2025, 03:37 UTC
Message-ID: <20250619033746.GA1801319@coredump.intra.peff.net>
In-Reply-To: <9cc42f04-856b-4967-8668-a47271af061c@intel.com>

On Wed, Jun 18, 2025 at 04:15:03PM -0700, Jacob Keller wrote:

Show 23 quoted lines

> On 6/18/2025 2:08 PM, Phil Hord wrote:
> > My patch fixes this for fetch, but it affects the command's output order.
> > Currently the results look like this:
> > 
> >      - [deleted]     (none) -> origin/bar
> >        (origin/bar has become dangling)
> >      - [deleted]     (none) -> origin/baz
> >      - [deleted]     (none) -> origin/foo
> >        (origin/foo has become dangling)
> >      - [deleted]     (none) -> origin/frotz
> > 
> > After my change, the order will change so the danglers are reported at the end.
> > 
> >      - [deleted]     (none) -> origin/bar
> >      - [deleted]     (none) -> origin/baz
> >      - [deleted]     (none) -> origin/foo
> >      - [deleted]     (none) -> origin/frotz
> >        (origin/bar has become dangling)
> >        (origin/foo has become dangling)
> 
> Personally, I like the later output. I have no idea why anyone would be
> specifically scripting something that depends on the ordering being such
> that dangling messages are printed immediately.

I think the original ordering tells you which deletion caused the ref to become dangling. Phil's example is a little confusing here:

    - [deleted]     (none) -> origin/bar
      (origin/bar has become dangling)

because the name is the same in both cases. A more likely output is that origin/HEAD becomes dangling (since it's the only symref Git ever automatically points at a tracking ref). E.g., in this:

  git init repo
  cd repo
  
  git commit --allow-empty -m foo
  git branch some
  git branch other
  git branch branches
  
  git clone . child
  cur=$(git symbolic-ref --short HEAD)
  git checkout some
  git branch -d other branches $cur
  
  cd child
  git fetch --prune

The final fetch output looks like:

   - [deleted]         (none)     -> origin/branches
   - [deleted]         (none)     -> origin/main
     (refs/remotes/origin/HEAD has become dangling)
   - [deleted]         (none)     -> origin/other

and we can see that the deletion of "main" is what caused the dangling.

That said, I'm not sure I care that much. I didn't even know we had this dangling message, and it's been around for over 15 years!

If we did want to preserve the ordering, it could be done by taking two passes (the first to create a reverse map of deletions to danglers, and then the second to print each ref).

Alternatively, the dangling message could just mention where it the now-dangling symref points at, something like:

   - [deleted]         (none)     -> origin/branches
   - [deleted]         (none)     -> origin/main
   - [deleted]         (none)     -> origin/other
     (refs/remotes/origin/HEAD points to the now-deleted origin/main)

I dunno. I guess anybody who really cares can run "git symbolic-ref origin/HEAD" themselves to get that information.

-Peff