Github – Unerwartete Trennung beim Lesen des Seitenbandpakets

Ich habe ein ziemlich interessantes Problem. Ich habe versucht, einige Projekte per Bash an Repo zu senden, und kürzlich gab es ein Problem beim Senden.

Enumerating objects: 27, done.
Counting objects: 100% (27/27), done.
Delta compression using up to 16 threads
Compressing objects: 100% (24/24), done.
Writing objects: 100% (25/25), 187.79 KiB | 9.39 MiB/s, done.
Total 25 (delta 1), reused 0 (delta 0), pack-reused 0
send-pack: unexpected disconnect while reading sideband packet
fatal: the remote end hung up unexpectedly

Das lustige daran ist, dass ich es 10 min früher ohne Probleme versenden kann.

Ich habe versucht, ein neues Repo zu bekommen, eine neue Datei zu erstellen, Git neu zu installieren, git config --global http.postBuffer 524288000 bei größeren Nummern auch https.postBuffer und so weiter. Installieren Sie auch die Desktop-Version. Das gleiche Problem tritt auf.

Ich habe hauptsächlich Probleme mit React-Apps.

Kennt jemand die Lösung? Was könnte schiefgehen ?

Überprüfen Sie zunächst die Stabilität Ihrer Netzwerkverbindung.

Wenn es kein Problem mit der Netzwerkverbindung gibt, versuchen Sie eine andere Lösung; es kann funktionieren:

Unter Linux

Führen Sie Folgendes in der Befehlszeile aus, bevor Sie den Git-Befehl ausführen:

export GIT_TRACE_PACKET=1
export GIT_TRACE=1
export GIT_CURL_VERBOSE=1

Unter Windows

Führen Sie Folgendes in der Befehlszeile aus, bevor Sie den Git-Befehl ausführen:

set GIT_TRACE_PACKET=1
set GIT_TRACE=1
set GIT_CURL_VERBOSE=1

Zusätzlich:

git config --global core.compression 0
git clone --depth 1 <repo_URI>
# cd to your newly created directory
git fetch --unshallow 
git pull --all

Für PowerShell-Benutzer:

Wie kodybrown in den Kommentaren sagte:

$env:GIT_TRACE_PACKET=1
$env:GIT_TRACE=1
$env:GIT_CURL_VERBOSE=1

Es könnte Ihr Netzwerkproblem sein. Wenn das Netzwerk zu langsam ist, wird die Verbindung möglicherweise unerwartet getrennt.

Wenn Sie ein gutes Internet haben und diese Nachricht immer noch erhalten, liegt möglicherweise ein Problem mit Ihrem Postpuffer vor. Verwenden Sie diesen Befehl, um es zu erhöhen:

git config --global http.postBuffer 157286400

Laut Dokumentation unter https://git-scm.com/docs/git-config#Documentation/git-config.txt-httppostBuffer:

Maximale Größe des Puffers in Bytes, der von intelligenten HTTP-Transporten verwendet wird, wenn Daten per POST an das Remotesystem gesendet werden. Für Anfragen, die diese Puffergröße überschreiten, wird HTTP/1.1 und Transfer-Encoding: chunked verwendet, um zu vermeiden, dass lokal eine riesige Paketdatei erstellt wird. Der Standardwert ist 1 MiB, was für die meisten Anfragen ausreicht.

Beachten Sie, dass das Erhöhen dieses Limits nur zum Deaktivieren der Chunked Transfer Encoding wirksam ist und daher nur verwendet werden sollte, wenn der Remote-Server oder ein Proxy nur HTTP/1.0 unterstützt oder nicht mit dem HTTP-Standard kompatibel ist. Das Erhöhen dieses Werts ist im Allgemeinen keine effektive Lösung für die meisten Push-Probleme, kann jedoch den Speicherverbrauch erheblich erhöhen, da der gesamte Puffer selbst für kleine Pushs zugewiesen wird.

Dies ist also nur eine Abhilfe in Fällen, in denen der Server Probleme hat. Dies wird höchstwahrscheinlich keine Push-Probleme auf GitHub oder GitLab.com beheben.

Ich wollte es nicht glauben, aber nach 3 fehlgeschlagenen Klonen funktionierte es beim ersten Mal, als ich von einer WLAN-Verbindung (auf Mac) zu einer fest verdrahteten Verbindung (unter Linux) wechselte. Nicht sicher warum!

https://serverfault.com/questions/1056419/git-wsl2-ssh-unexpected-disconnect-while-reading-sideband-packet/1060187#1060187

Ich hatte das gleiche Problem. Ich habe ein Repo mit 20000 Dateien, das gesamte Repo ist etwa 5 GB groß und einige Dateien sind 10 MB groß. Ich konnte mich ohne Probleme auf das Repo festlegen und ich konnte ohne Probleme klonen (es dauerte jedoch eine Weile). Doch jedes andere Mal, wenn ich dieses Repo auf meine Maschine zog, bekam ich es

remote: Enumerating objects: 1359, done.
remote: Counting objects: 100% (1359/1359), done.
remote: Compressing objects: 100% (691/691), done.
remote: Total 1221 (delta 530), reused 1221 (delta 530), pack-reused 0
fetch-pack: unexpected disconnect while reading sideband packet
fatal: early EOF
fatal: fetch-pack: invalid index-pack output

Was letztendlich geholfen hat, war dieser Tipp. Gehen Sie in Ihr Benutzerverzeichnis und bearbeiten Sie es .git/config und füge hinzu:

[core] 
    packedGitLimit = 512m 
    packedGitWindowSize = 512m 
[pack] 
    deltaCacheSize = 2047m 
    packSizeLimit = 2047m 
    windowMemory = 2047m

Voilà. Keine Fehler mehr.

In meinem Fall hatte ich einige Dateien, die über 100 MB groß waren, als ich versuchte, meinen ersten Commit zu pushen. Da GitHub dies anscheinend nicht zulässt, erhalten Sie einen Fehler “unerwarteter Verbindungsabbruch beim Lesen des Seitenbandpakets fatal: Das entfernte Ende hat unerwartet aufgelegt”.

Die Verwendung von git rm war nicht genug, ich musste mit git init, git add, git commit und git push von vorne beginnen, um das Problem zu lösen.

Wenn Sie SSH-URLs verwenden, können Sie Folgendes versuchen. Bei mir hat es zweimal funktioniert, als ich das gleiche Problem hatte:

1. Zur HTTPS-Ursprungs-URL wechseln: git remote set-url origin https://github.com/<your_repo>
2. Mach den Stoß. Daran soll es jetzt nicht scheitern.
3. Zurück zu SSH wechseln: git remote set-url origin [email protected]:<your_repo>

Ich bin mir immer noch nicht sicher, was die Ursache des Problems ist. Dies ist nur eine Umgehung.

In meinem Fall habe ich diesen Fehler beim ersten Commit in ein neues Repo erhalten.

Ich habe einfach den .git-Ordner gelöscht und dann ein paar Dateien auf einmal hinzugefügt, wobei ich mit jeder Hinzufügung festgeschrieben habe.

Ich habe es geschafft, alles wieder hinzuzufügen, ohne auf denselben Fehler zu stoßen.