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

[Jacob Keller <jacob.e.keller@intel.com>]

On 6/23/2025 4:11 PM, Phil Hord wrote:
> On Wed, Jun 18, 2025 at 8:37 PM Jeff King <peff@peff.net> wrote:
>> On Wed, Jun 18, 2025 at 04:15:03PM -0700, Jacob Keller wrote:
>>> 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
> 
> Thanks for the helpful demo and clarification of the real output.
> 
>> 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 have a new patch that produces this:
> 
>     + git fetch --prune --dry-run
>     From /tmp/repo/.
>      - [deleted]                   (none)     -> origin/branches
>      - [deleted]                   (none)     -> origin/master
>      - [deleted]                   (none)     -> origin/other
>        origin/HEAD will become dangling after origin/master is deleted
> 


It is a bit weird that this says "will become dangling after <ref> is
deleted" because the deletion already happened.