Re: [PATCH v4 0/4] refs: run copy and rename through transactions

From: Maciej Ciemborowicz <maciej.ciemborowicz@gmail.com>
Date: Oct 10, 2026, 00:06 UTC
Message-ID: <CACQ=SRHe_gKjr+-TSvo7F+L=vXeV0TwFGRAYJ52bf+09adBFOw@mail.gmail.com>
In-Reply-To: <CAOLa=ZTtLcSPop-A3y-kOv5h-0D-Kq2P+QUpKTEcmU5z77eJYg@mail.gmail.com>

> At some point I felt it would've been faster if I used a LLM locally for

the same task and reviewed its code instead.

If writing the patches on your end would be more efficient than reviewing mine, I'd be more than happy to go with that approach. Ultimately, my main goal is simply to get both issues resolved, the one discussed here and the one in the thread you referenced. I don't want to hold you back.

Thanks, Maciej

On Fri, Oct 9, 2026 at 11:21 PM Karthik Nayak <karthik.188@gmail.com> wrote:

Show 39 quoted lines

>
> Junio C Hamano <gitster@pobox.com> writes:
>
> > Patrick Steinhardt <ps@pks.im> writes:
> >
> >> On Thu, Oct 08, 2026 at 11:44:15AM +0200, Maciej Ciemborowicz wrote:
> >>> Changes since v3:
> >>>
> >>> * Rebase onto 6de20f6092 (The 4th batch, 2026-10-06), the master commit
> >>>   used in Junio's report.
> >>> * Preserve the packed preparation error in patch 2 as described above.
> >>> * Register t1425 and t1424 in t/meson.build in the commits adding them.
> >>
> >> Please engage with the reviewers. Just posting new versions without
> >> replying to them at all will very likely not get you anywhere. This kind
> >> of behaviour is nowadays a red flag and often hints at contributors who
> >> are basically just a meat proxy. And as a consequence, reviewers are
> >> very likely to disengage and stop reviewing your patch series
> >> altogether, which is frustrating to everyone involved.
> >
> > Thanks for bringing this up.
> >
> > A response to reviews on the N-th round must come long before
> > sending the v(N+1) round of patches.  Some contributors send them
> > after v(N+1), or immediately before, but the proper time to respond
> > is soon after receiving the reviews on vN and having had enough time
> > to understand the comments, before starting work on v(N+1).  Only
> > after that work is complete would you send the new patches.  Hence,
> > we expect the time between vN and v(N+1) from real contributors to
> > be measured in days, not hours.  Whenever I see vN responses arrive
> > after or immediately before the v(N+1) patches, or worse, no
> > response at all but just the new patches, it smells fishy.
>
> This is kinda why I stopped reviewing the other patches [1] from the
> author, my reviews were simply met with N+1 version of the series. At
> some point I felt it would've been faster if I used a LLM locally for
> the same task and reviewed its code instead.
>
> [1]: https://lore.kernel.org/git/CACQ=SRGTTdQ+dHXhN6F52dBv5KxZBRfk_Em2fvmEmGJDoB6oTg@mail.gmail.com/