On 11/18/16 22:53, Clemens John via Admin wrote:
 Am Freitag, 18. November 2016, 12:35:58 CET schrieb Clemens John via Admin:
 Ich habe dazu etwas recherchiert und folgendes hat bei meinem Netmon Web-
 Client Repo geholfen:
 http://joemaller.com/1283/git-error-index-file-is-too-small/

 Hatte den Fehler schonmal jemand und kann dazu etwas mehr sagen als ich?
 Nicht dass ich die Fehlerbehebung jetzt auf alle Repos anwende und dann
 mehr kaputt mache als heile :D

 Hi,

 Teilerfolg! Ich habe den Vorschlag jetzt mit folgendem Script auf alle Repos 
 angewendet (Backup
existiert):

 +++
 #!/bin/bash
 for namespace in /var/opt/gitlab/git-data/repositories/*;
 do 
   for repo in "$namespace"/*;
   do 
     [ -d $f ] && cd "$repo" && echo "Entering into $repo" && git repack -a -d
   done;
 done;
 +++

 Jetzt kann man die Repos klonen ohne Fehlermeldungen zu bekommen. Mein 
 Eindruck ist auch, dass da nichts verloren gegangen ist.

:S oh oh ich bin skeptisch ...

 Probleme gibt es allerdings nach wie vor beim Pushen. Neue Dateien kann ich 
 pushen, aber alte Dateien modifizieren geht wohl nicht. Zumindest konnte ich 
 die in der letzten Woche bei mir angesammelten Commits nicht pushen:

 +++
 [floh1111@flohlap api-server_fixed]$ git push --verbose
 Versende nach
git@git.ffnw.de:netmon-sc/api-server.git
 Enter passphrase for key '/home/floh1111/.ssh/id_rsa': 
 Zähle Objekte: 49, Fertig.
 Delta compression using up to 4 threads.
 Komprimiere Objekte: 100% (18/18), Fertig.
 Schreibe Objekte: 100% (49/49), 8.11 KiB | 0 bytes/s, Fertig.
 Total 49 (delta 32), reused 45 (delta 31)
 remote: error: unable to create temporary file: Not a directory
 remote: fatal: failed to write object
 error: unpack failed: unpack-objects abnormal exit
 To git.ffnw.de:netmon-sc/api-server.git
  ! [remote rejected] master -> master (unpacker error)
 error: Fehler beim Versenden einiger Referenzen nach 'git@git.ffnw.de:netmon-
 sc/api-server.git'
 +++

 Zu "remote: error: unable to create temporary file: Not a directory" ist Google 
 nicht sehr ergiebig sodass ich mich jetzt an der Brutalo-Methode versucht 
 habe, siehe https://forum.gitlab.com/t/how-can-i-delete-a-repository-and-push-a-new-one/690/3

 1. korrumpiertes Repos auf den lokalen Rechner klonen
 2. Das Repo unter /var/opt/gitlab/git-data/repositories/ vom Server löschen
 3. Die Gitlab-URL des dazugehörenden Projekts aufrufen und ein neues leeres 
 Repo erzeugen.
 4. Das vorher geklonte Repo pushen

 Da wir nicht genau wissen, welche Repos betroffen sind, könnte man den Prozess 
 immer dann ausführen, wenn man beim Pushen in ein Repo ein betroffenes Repo 
 findet. Bis alle Repos wieder clean sind, kann sich das natürlich hinziehen. 
 Was meint ihr?

Also Clemens ich weiß ja nicht ob es die auch so geht, aber wirklich
überzeugt bin ich von der Lösung nicht.
Wollen wir mal testen ob die Probleme auch auftreten wenn wir kein
omnibus nehmen sondern
wieder zum alten setup?

vg
Tarek