Subject: Re: data loss when doing ls-remote and piped to command

From: Junio C Hamano <[email-masked]>
Date: Wed, 15 Sep 2021 11:17:42 -0700

Rolf Eike Beer <[email-masked]> writes:

> The given repository is a clone of the vanilla kernel.
>
> /usr/bin/git --git-dir=/home/ebeer/repos/upstream/linux/.git ls-remote origin 2>&1 | less
>
> And I then see things like this:
>
> 6f38b5d6cfd43dde3058a10c68baae9cf17af912        refs/tags/v5.0-rc2
> 1c7fc5cbc33980acd13ae83d0b416db002fe95601e7f97f64b59514d936     refs/tags/v5.7-rc2^{}
> d0709bb6da2ab6d49b11643e98abdf79b1a2817f        refs/tags/v5.7-rc3

Not offering any solution, just an observation of the problem and
annotating the report.

What we see on the second line is the beginning of peeled
v5.0-rc2^{} up to the "acd13" (that is, the first 19 bytes of the
line), followed by the full line for peeled v5.7-rc2^{} (which
begins with "ae83d").  12407 bytes in between are missing, which
is even more puzzling as it is not a nice round number.

I wonder if this is "less" misconfigured and misbehaving.  Did the
user after seeing v5.7-* tags scroll back with 'b' or something?

If the output (including the 2>&1 redirection) is sent to a file and
then "cat <that-file" is invoked, does the same thing happen?  How
about "cat <that-file | less"?