Git-Fehler: RPC ist fehlgeschlagen; Ergebnis = 22, HTTP-Code = 404

Juni 2016 Update: Nach dieser Seite :

  

Die SSH-Authentifizierung für Team Services Git Repos befindet sich derzeit in einer privaten Vorschau

Ich empfehle Ihnen, wenn Sie dazu in der Lage sind, zur SSH-Authentifizierung zu wechseln, da dies das gesamte Problem vermeiden sollte. (Beachten Sie, dass Sie in der Lage sind, die Verwendung von HTTPS und SSH in tandem, auch auf der gleichen Maschine .)

Wenn dies noch nicht für Sie aktiviert wurde oder Sie auf andere Weise nicht zu SSH wechseln können, lesen Sie weiter.

Originalbeitrag:

Wie schon von @ Oxymoron erwähnt, besteht das Problem darin, dass Ihr Repository zu groß ist, oder genauer gesagt, Sie versuchen, zu viel auf einmal zu tun.

  

Was? Das ergibt keinen Sinn! Dafür ist der HTTP 404 Code nicht geeignet!

Es ergibt auch keinen Sinn für mich. * glänzt in Microsofts allgemeiner Richtung *

Sie haben das wahrscheinlich schon bemerkt und einen Fehler wie folgt bekommen:

Und das hat wahrscheinlich dazu geführt, dass Sie den von Ihnen erwähnten Befehl git config ausgeführt haben.

Nun zum Zweck meiner Veröffentlichung eine separate Antwort: Ich würde gerne näher erläutern, wie Sie das beheben können. Sie werden immer noch versuchen, einen kleineren Satz von Commits auf einmal zu schieben, aber das ist nicht immer so einfach wie es klingt. Hier ist der Prozess:

1. Legen Sie fest, wie viele Commits gleichzeitig ausgeführt werden sollen. Ich würde normalerweise eine binäre Suche empfehlen, um zu bestimmen, wie viel Sie schieben können, aber das kann wegen der Wartezeit zwischen den Drücken schwierig sein. Außerdem haben viele Repos einen sehr großen ersten Commit, oder bestimmte Commits danach sind sehr groß. Wenn Sie solche Commits kennen, versuchen Sie diese selbst zu pushen. Wenn Ihr Repo klein genug ist, ist es am einfachsten, nur einen Commit zu einem Zeitpunkt durchzuführen. Andernfalls versuchen Sie, 20-30 Commits zu drücken, verringern Sie die Anzahl, wenn Probleme auftreten.

2. Angenommen, Sie haben einen Zweig, master , erstellen Sie einen neuen Zweig am selben Ort, z. master-temp .

3. Setzen Sie master auf das letzte Commit in der ersten Gruppe, die Sie übertragen möchten. Z.B. git reset --hard master-temp~100 .

4. Drücken Sie diesen Commit ( git push ).

5. Führe --ff beim letzten Commit der nächsten Gruppe zusammen. ( git merge --ff-only master-temp~90 )

6. Wiederholen Sie die Schritte 4 und 5, bis alle Commits durchgeführt wurden.

Betrachten Sie als Beispiel dieses Repo:

Dies ist, was Sie tun werden, unter der Annahme, dass Sie einen Commit nach dem anderen schieben wollen:

Im Idealfall funktioniert das gut und Sie sind fertig. Aber was passiert, wenn ein bestimmtes Commit nicht gepusht werden kann, selbst wenn das die einzige Verpflichtung ist, die Sie schieben? Versuchen Sie es zunächst einmal oder zweimal. Es scheint einige Unstimmigkeiten zu geben, wie viel es braucht, um den Push zu scheitern.

Wenn es immer noch nicht drücken wird, ist es Zeit, den Verlauf neu zu schreiben.

  

Aber ich möchte meine Geschichte nicht umschreiben! Mein Git Protokoll ist schön und sauber, weil ich viel Zeit damit verbracht, zu lernen, wie Sie schreiben große Nachrichten begehen, und Ich halte meine Commits immer atomar .

Mach dir keine Sorgen, du bekommst immer noch deinen ursprünglichen Verlauf, wenn du fertig bist.

Zurück zum (aktualisierten) Beispiel Repo:

(Das massive Commit kann irgendwo sein, oder es kann mehr als eins geben.)

Die allgemeine Idee ist, haben Sie eine interaktive rebase ( git rebase -i ) auf die massiven in ein paar kleineren begehen geteilt .

Hinweis: --root wird nur benötigt, wenn Sie das allererste Commit teilen müssen. Anderenfalls z.B. git rebase -i bbbbbbb .

Ändern Sie das Commit, das Sie teilen möchten, von pick in edit .

Nun ist dies, wo die magit Magie passiert:

Der letzte Befehl wird erfolgreich ausgeführt, da Git intelligent genug ist, um die Elemente, die Sie bereits verschoben haben, wiederzuverwenden, selbst wenn sie in einem anderen Commit sind . (Beachten Sie, dass der Schritt Analyzing objects derjenige ist, der am längsten dauert. Git berechnet, wie viel es wiederverwenden kann und wie viel es hochladen muss.) Wenn Sie mehr darüber erfahren möchten, wie das funktioniert, sehen Sie sich das an Packfiles-Abschnitt der Git Internals-Dokumentation , vielleicht nach dem Aufräumen von Git Objekte .

Habe ich erwähnt, dass Git großartig ist?

Ich bin gerade auf einen sehr ähnlichen Fehler gestoßen (für den diese Antwort das beste Google-Ergebnis ist) - die Lösung war in einem Kommentar von @Liviu Chircu

Die Lösung war, das .git auf das Ende der URL zu setzen

Allerdings:

ist erfolgreich.

Das seltsame ist, dass die ursprüngliche URL ohne .git auf zwei Linux-Rechnern und einem Windows-Desktop erfolgreich war, aber auf einem dritten Linux-Rechner fehlschlug. Einschließlich .git funktioniert es auf allen Maschinen.