it-swarm.com.de

git Unpack Error bei Push to gerrit

Beim Push eines neuen Zweigs auf einen Gerrit-Server tritt der folgende Fehler auf:

[email protected]:~/git-hate/www$ git Push Origin landingpage
Counting objects: 149, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (73/73), done.
Writing objects: 100% (111/111), 2.77 MiB, done.
Total 111 (delta 68), reused 80 (delta 38)
remote: Resolving deltas: 100% (68/68)
error: unpack failed: error Missing tree 30c4809ade0b4b0c81cb7f882450774862b82361
fatal: Unpack error, check server log
To ssh://[email protected]/repository
 ! [remote rejected] landingpage -> landingpage (n/a (unpacker error))
error: failed to Push some refs to 'ssh://[email protected]/repository'

Wir haben versucht, das erwähnte Tree-Objekt manuell auf das Remote-Git zu kopieren, ohne Erfolg.

Auf gerrit Seite bekommen wir einen Stacktrace:

[2013-05-16 13:43:42,753] ERROR com.google.gerrit.sshd.BaseCommand : Internal server error (user de account 1000000) during git-receive-pack '/repository'
com.google.gerrit.sshd.BaseCommand$Failure: fatal: Unpack error, check server log
        at com.google.gerrit.sshd.commands.Receive.runImpl(Receive.Java:157)
        at com.google.gerrit.sshd.AbstractGitCommand.service(AbstractGitCommand.Java:106)
        at com.google.gerrit.sshd.AbstractGitCommand.access$000(AbstractGitCommand.Java:34)
        at com.google.gerrit.sshd.AbstractGitCommand$1.run(AbstractGitCommand.Java:72)
        at com.google.gerrit.sshd.BaseCommand$TaskThunk.run(BaseCommand.Java:430)
        at Java.util.concurrent.Executors$RunnableAdapter.call(Executors.Java:471)
        at Java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.Java:334)
        at Java.util.concurrent.FutureTask.run(FutureTask.Java:166)
        at Java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.Java:165)
        at Java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.Java:266)
        at com.google.gerrit.server.git.WorkQueue$Task.run(WorkQueue.Java:337)
        at Java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.Java:1110)
        at Java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.Java:603)
        at Java.lang.Thread.run(Thread.Java:636)
Caused by: Java.io.IOException: Unpack error on project "repository":
  AdvertiseRefsHook: [email protected] org.Eclipse.jgit.transport.AdvertiseRefsHookChain

        at com.google.gerrit.sshd.commands.Receive.runImpl(Receive.Java:156)
        ... 13 more
Caused by: org.Eclipse.jgit.errors.UnpackException: Exception while parsing pack stream
        at org.Eclipse.jgit.transport.ReceivePack.service(ReceivePack.Java:202)
        at org.Eclipse.jgit.transport.ReceivePack.receive(ReceivePack.Java:142)
        at com.google.gerrit.sshd.commands.Receive.runImpl(Receive.Java:98)
        ... 13 more
Caused by: org.Eclipse.jgit.errors.MissingObjectException: Missing tree 30c4809ade0b4b0c81cb7f882450774862b82361
        at org.Eclipse.jgit.transport.BaseReceivePack.checkConnectivity(BaseReceivePack.Java:996)
        at org.Eclipse.jgit.transport.BaseReceivePack.receivePackAndCheckConnectivity(BaseReceivePack.Java:756)
        at org.Eclipse.jgit.transport.ReceivePack.service(ReceivePack.Java:167)
        ... 15 more

Leute: irgendwelche Ideen, was zu tun?

56
edlerd

Drücken mit --no-thin Argument funktioniert als Workaround für mich:

git Push --no-thin omnigerrit HEAD:refs/for/Android-4.4
99
Tassadar

Verwenden Sie git> 1.8.4.2?

Ich habe eine Inkompatibilität zwischen git 1.8.4.3+ und gerrit 2.6 festgestellt, weil https://github.com/git/git/commit/fbd4a7036dfa71ec89e7c441cef1ac9aa59a315

Wenn git mit dieser Erweiterung feststellt, dass der Baum sha1 bereits auf dem Server vorhanden ist, wird er nicht erneut gesendet, aber gerrit möchte den Baum sha1 durchsuchen, der dem Commit sha1 im hochgeladenen Paket zugeordnet ist.

Es sieht so aus, als ob ich es nicht mit Gerrit 2.8-RC3 reproduzieren kann, nicht mit der neuesten Version von SCM-Manager. Ich würde sagen, dies wurde in JGIT behoben, kann aber noch nicht finden, welche Version.

13
tardyp

mein Fall

Auch dieses Problem tritt auf, und es dauert lange, bis es behoben ist.

Erstens stelle ich eine Fehlerinformation im Gerrit-Protokoll fest:

Internal server error (user newptone account 1) during git-receive-pack                           '/neutron.git' 
com.google.gerrit.sshd.BaseCommand$Failure: fatal: Unpack error,   check server log
......
... Missing unknown 613fd2557fba30aff2dbd51c3807cc57561bab08

Was ist das Objekt 613fd2557fba30aff2dbd51c3807cc57561bab08?

Dann benutze ich git review -l, um alle geöffneten Patchsets nach diesem Projektneutron zu durchsuchen:

1974  master  Add two interfaces for manipulate forwarding individually

Dann finde ich dieses Patchset im Gerrit-Dashboard, indem ich suche, auf den Link klicke und es scheint ein Fehler zu sein:

613fd2557fba30aff2dbd51c3807cc57561bab08 cannot  found

Aha, das ist der Grund!

Aber warum fehlt dieses Objekt?

Der Grund ist, dass mein Kollege mir sagt, dass Neutronenprojekt ein neues Repo verwenden wird, um das alte zu ersetzen. Ich lösche das alte Repo, habe aber nicht alle offenen Patch-Sets in Gerrit geschlossen. Das geöffnete Patchset verschwindet im Gerrit-Dashboard, ist jedoch in der Gerrit-Datenbank noch vorhanden.

wie man es repariert

Loggen Sie sich in Ihre Rezension ein und finden Sie diesen Datensatz:

Stellen Sie zunächst sicher, dass dies derjenige ist, den wir ändern möchten:

select * from changes where change_id=1974\G;

Dann aktualisiere diesen Datensatz:

update changes set open='N',status='A' where change_id=1974;
10
NewPtone

Ich bin gerade auch auf diesen Fehler gestoßen.

In meinem Szenario habe ich versucht, ein geändertes Commit zu pushen, bei dem sich seit dem letzten Pushen des gleichen Commits keine der Dateien geändert hat. Ich hatte die Festschreibungsmeldung für die Änderung buchstäblich gerade geändert und versuchte, erneut zu pushen. Es wurden keine Dateien im Rahmen des Commits geändert.

Mein Push wurde mit derselben Fehlermeldung abgelehnt, die Sie gesendet haben.

Es schien, dass Gerrit keinen Push mochte, außer der geänderten Commit-Nachricht.

Ich habe buchstäblich eine Änderung von einem Zeichen an einer Datei vorgenommen, die Datei hinzugefügt, den Commit erneut geändert und einen Push ausgeführt, und der Push war erfolgreich.

Ich benutze git == 1.8.4.2

7
Andy Obusek

Ich hatte heute dieses Problem und habe alle Vorschläge ausprobiert. Schließlich war die Lösung sehr einfach:

  1. Wechseln Sie zu einem anderen Zweig (z. B. Entwickeln).
  2. Aus dem Remote-Repository ziehen
  3. Wechseln Sie zurück zu Ihrem neuen Zweig und drücken Sie.

Mit etwas Glück klappt es jetzt.

6
obrienk

Ich bin heute auf dieses Problem gestoßen und habe git> 1.8.4.2 nicht verwendet. Ich bin auf Gerrit 2.7.

Nach ungefähr 5 Minuten der Frustration entschied ich mich, einfach zu der lokalen Version des Zweigs zu wechseln, zu dem ich pushen wollte, und zog daran. Danach haben meine Schübe wieder funktioniert, aber ich verstehe nicht warum.

2
onlywei

Ich komme gerade mit diesem Problem, und mein Fall ist: Jemand initialisiert git und pusht einen ganz neuen Zweig (das heißt, dieser Zweig steht in keiner Beziehung zu einer Revision in Origin git in gerrit) zu einem git-Projekt in gerrit . Ich versuche viele Wege, aber scheitere. Am Ende inspiriert mich die Antwort von @obuseme, folge dieser und behebe Folgendes:

git remote add gerrit GERRIT_GIT_PROJECT_URL
git fetch gerrit
And then upload again.
1
Chunlin Zhang

Ich habe dieses Problem umgangen, indem ich das Repository erneut geklont und meine Änderungen vom alten kopiert habe.

Die anderen Lösungen haben bei mir nicht funktioniert, außer ich habe keine obrienks ausprobiert.

Ich habe es sowohl mit git 2.6.1 als auch mit JGit 4.6.1 versucht und ich benutze Gerrit 2.13.1.

0
Max Hohenegger

Wenn der Fehler beim Entpacken auftritt, sollten Sie auch nach dieser Zeile suchen: remote: error: unable to create temporary file: No space left on device

Durch das Löschen einiger alter Sicherungsdateien wurde genügend Speicherplatz freigegeben, damit das System wieder funktioniert.

0
Frank Forte