From: Rolf Eike Beer <eb@emlix.com>
To: git@vger.kernel.org
Subject: data loss when doing ls-remote and piped to command
Date: Wed, 15 Sep 2021 14:43:10 +0200 [thread overview]
Message-ID: <6786526.72e2EbofS7@devpool47> (raw)
[-- Attachment #1: Type: text/plain, Size: 2250 bytes --]
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
This also happens when I cd into the repository and just run "git ls-remote"
on some of my repositories, but much less often.
The remainder of the overly long line is the correct id for that tag. The
error does not happen on every run, and on some of my repositories it also
differs from run to run on which tag that happens. Here it seems that it is
quite stable to happening on this tag. However, a different user on the same
machine running the very same command had it happen on v5.7-rc3.
I have the same on my laptop, both run on Opensuse Tumbleweed, updated at the
same time this morning. This seems to be quite fragile regarding latency or
such: I can reproduce it with our internal git server, but not with
kernel.org. This is not bound to less, we originally observed the error on a
entirely different tool that tried to parse the output of ls-remote.
Given that there are quite a lot of tags missing I suspect it may be that the
pipe handling is somewhere broken, i.e. too much data is written to a pipe
that is already full. I have not been able to provoke that using pv by rate
limiting the output so far.
[System Info]
git Version:
git version 2.33.0
cpu: x86_64
no commit associated with this build
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
uname: Linux 5.14.1-1-default #1 SMP Sat Sep 4 08:22:51 UTC 2021 (67af907) x86_64
Compiler Info: gnuc: 11.2
libc Info: glibc: 2.33
$SHELL (typically, interactive shell): /bin/bash
[no hooks]
--
Rolf Eike Beer, emlix GmbH, http://www.emlix.com
Fon +49 551 30664-0, Fax +49 551 30664-11
Gothaer Platz 3, 37083 Göttingen, Germany
Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160
Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055
emlix - smart embedded open source
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 313 bytes --]
next reply other threads:[~2021-09-15 12:52 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-15 12:43 Rolf Eike Beer [this message]
2021-09-15 18:17 ` data loss when doing ls-remote and piped to command Junio C Hamano
2021-09-16 6:38 ` Rolf Eike Beer
2021-09-16 10:12 ` Tobias Ulmer
2021-09-16 12:17 ` Rolf Eike Beer
2021-09-16 15:49 ` Mike Galbraith
2021-09-17 6:38 ` Mike Galbraith
2021-09-16 17:11 ` Linus Torvalds
2021-09-16 20:42 ` Junio C Hamano
2021-09-17 6:59 ` Rolf Eike Beer
2021-09-17 19:13 ` Jeff King
2021-09-17 19:28 ` Linus Torvalds
2021-09-18 6:33 ` Mike Galbraith
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6786526.72e2EbofS7@devpool47 \
--to=eb@emlix.com \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).