Re: [PATCH] maintenance: add prune-remote-refs task

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

 



On Fri, Dec 27, 2024 at 2:37 PM Junio C Hamano <gitster@xxxxxxxxx> wrote:
>
> Thanks for a patch.
>
>
> "Shubham Kanodia via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes:
>
> You'd want to check your procedure to tell GGG about addresses; I am
> seeing these
>
>     From: "Shubham Kanodia via GitGitGadget" <gitgitgadget@xxxxxxxxx>
>     To: git@xxxxxxxxxxxxxxx
>     Cc: "mailto:gitster@xxxxxxxxx"; <[gitster@xxxxxxxxx]>,
>             "mailto:ps@xxxxxx"; <[ps@xxxxxx]>,
>             Shubham Kanodia <shubham.kanodia10@xxxxxxxxx>,
>             Shubham Kanodia <shubham.kanodia10@xxxxxxxxx>
>
> and Cc addresses in it would probably not work as-is (I've fixed
> them up manually).

I think the GGG comment had a few formatting errors. Thanks for fixing the cc.

> Hmph, is there a reason why you need two loops, instead of
> for-each-remote calling a function that does the run_command()
> thing?

It can be collapsed into one.

> This loop does not stop at the first error, but returns a non-zero
> error after noticing even a single remote fail to run prune, which
> sounds like a seneible design.  Would an error percolate up the same
> way when two different tasks run and one of them fails in the
> control folow in "git maintenance"?  Just want to see if we are
> being consistent with the surrounding code.

Fair point. I'll make the process flow identical to the prefetch refs
task that works similarly across remotes.
It returns as soon as the first remote fails (without necessarily
affecting other tasks).





[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