Re: Anyone know why git ls-remote output might be corrupted?

From: Paul Smith <paul@mad-scientist.net>
Date: Jun 12, 2023, 19:59 UTC
Message-ID: <21193d97d43094a01b4ac9442448135867e22c70.camel@mad-scientist.net>
In-Reply-To: <xmqqo7loo42s.fsf@gitster.g>

On Sat, 2023-06-10 at 03:58 +0900, Junio C Hamano wrote:

Show 19 quoted lines

> Paul Smith <paul@mad-scientist.net> writes:
> 
> > I also checked and indeed, the git ls-remote command does print to
> > both stdout and stderr as part of its "standard" behavior:
> > 
> >    $ git ls-remote --heads >/dev/null
> >    From git@git:myrepo
> > 
> > This is unexpected to me, although of course there's nothing
> > inherently wrong with it but usually you don't expect "regular"
> > output to go to stderr.  I suppose the idea is that people can run:
> > 
> >    $ git ls-remote --heads 2>/dev/null
> > 
> > if they want just the output without the header.
> 
> The above sounds like a reasonable expectation; then the issue is
> there are some fflush missing when the command writes to one stream
> and switches to write to another stream?

It's not immediately clear to me which "above" you refer to as a reasonable expectation (the reason for the stdout vs. stderr different I suppose?)

But I agree that forcing flush would be a good idea (or perhaps forcing line buffering? Changing buffering can be annoying to do portably), for situations in which the output is being sent to a non-TTY, because the default in that situation is fully buffered output.

Maybe it would be sufficient to have any output to stderr run fflush(stdout) before the output, and fflush(stderr) after the output. Presumably output to stderr is relatively rare, and so this wouldn't be very noticeable.