Re: [PATCH v4 0/4] refs: run copy and rename through transactions
- From
Karthik Nayak <karthik.188@gmail.com>
- Date
- Oct 9, 2026, 21:21 UTC
- Message-ID
- <CAOLa=ZTtLcSPop-A3y-kOv5h-0D-Kq2P+QUpKTEcmU5z77eJYg@mail.gmail.com>
- In-Reply-To
- <xmqqece02no9.fsf@gitster.g>
Junio C Hamano <gitster@pobox.com> writes:
Show 29 quoted lines
> 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/