Re: Re* 2.54.0-rc1 NO_WRITEV=Nope does not work

[Patrick Steinhardt <ps@pks.im>]

On Thu, Apr 09, 2026 at 03:31:46PM -0700, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
> 
> > On Thu, Apr 09, 2026 at 02:53:28PM -0700, Junio C Hamano wrote:
> >
> >> > Yuck. I think for 2.54 we either have to truly implement MAX_IO_SIZE
> >> > support, or we have to revert the use of writev() in send_sideband()
> >> > until we do.
> >> 
> >> Sigh again.
> >
> > Yeah, I feel the same way. :(
> >
> > I would be happy if somebody could prove me wrong, though.
> >
> >> $ git log -Swritev --oneline 8023abc632^..
> >> 89152af176 cmake: use writev(3p) wrapper as needed
> >> 26986f4cba sideband: use writev(3p) to send pktlines
> >> 1970fcef93 wrapper: introduce writev(3p) wrappers
> >> 3b9b2c2a29 compat/posix: introduce writev(3p) wrapper
> >> 
> >> Reverting them gave us the following patch relative to the tip of
> >> 'master'.
> >
> > If we are planning to improve the topic post-release (and I think that
> > is a good idea), then we can do a much smaller revert. If we just revert
> > 26986f4cba (sideband: use writev(3p) to send pktlines, 2026-03-13), then
> > nobody calls writev (neither the real one nor our fallback). The
> > wrappers are dead code until we bring it back, but it may make things
> > easier for fixing post-2.54.
> >
> > -Peff
> 
> Yes and no.  While excising know callers is certainly safer in the
> code space, I do not want to hear about some compilers complaining
> about dead code, etc.

I guess they wouldn't as the function signature is part of a header.

> I am preparing another set of integration to be pushed out, queueing
> the reverts in 'seen'.

But anyway, I'm okay with this as the safest way forward. I'll then
reintroduce early in the next release cycle and hopefully weed out the
existing issues.

Thanks, all!

Patrick