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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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.




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux