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

From: Jacob Keller <jacob.e.keller@intel.com>
Date: Jun 18, 2025, 23:15 UTC
Message-ID: <9cc42f04-856b-4967-8668-a47271af061c@intel.com>
In-Reply-To: <20250618211024.2332525-1-phil.hord@gmail.com>

On 6/18/2025 2:08 PM, Phil Hord wrote:

Show 18 quoted lines

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