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

From: Shubham Kanodia <shubham.kanodia10@gmail.com>
Date: Dec 28, 2024, 09:58 UTC
Message-ID: <CAG=Um+0a+ugf+gWUDS3htj3u2tewzOrH+xGbF+2A+w4ofjQfKg@mail.gmail.com>
In-Reply-To: <xmqqed1tv6hu.fsf@gitster.g>

On Fri, Dec 27, 2024 at 2:37 PM Junio C Hamano <gitster@pobox.com> wrote:

Show 18 quoted lines

>
> Thanks for a patch.
>
>
> "Shubham Kanodia via GitGitGadget" <gitgitgadget@gmail.com> writes:
>
> You'd want to check your procedure to tell GGG about addresses; I am
> seeing these
>
>     From: "Shubham Kanodia via GitGitGadget" <gitgitgadget@gmail.com>
>     To: git@vger.kernel.org
>     Cc: "mailto:gitster@pobox.com" <[gitster@pobox.com]>,
>             "mailto:ps@pks.im" <[ps@pks.im]>,
>             Shubham Kanodia <shubham.kanodia10@gmail.com>,
>             Shubham Kanodia <shubham.kanodia10@gmail.com>
>
> 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.

Show 6 quoted lines

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