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

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 15, 2021, 18:17 UTC
Message-ID: <xmqqwnnhwvnd.fsf@gitster.g>
In-Reply-To: <6786526.72e2EbofS7@devpool47>

Rolf Eike Beer <eb@emlix.com> writes:

Show 9 quoted lines

> 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"?