Größe der Packdateien unter Git beschränken

Im Versionsverwaltungssystem Git existieren im Repository sogenannte Packfiles. Diese werden genutzt um mehrere Objekte, wie z.B. Commits, Trees, Blobs oder Tags, als einzelne Dateien abzulegen. Damit fasst Git viele Objekte zu einer einzelnen komprimierten Datei zusammen. Ergänzt wird das ganze durch einen Index, um einen schnellen Zugriff zu ermöglichen. Dabei nutzt Git Delta-Kompression, indem es ähnliche Objekte, z. B. verschiedene Versionen derselben Datei, nicht vollständig speichert, sondern nur die Unterschiede.

Eine Git-Pack-Datei im Schema

Dies reduziert die Repository-Größe erheblich, kann aber bei ungünstigen Repositorys mit vielen Binärdaten zu Repositorys führen, welche mehrere dutzend Gigabyte große Pack-Dateien besitzen. Eine Steuerung ist über den Konfigurationsparameter pack.packsizelimit möglich:

git config pack.packsizelimit 5g

Damit würde diese Einstellung für das aktuelle Repository gesetzt werden. Wer das Ganze global benötigt, kann dies ebenfalls einstellen:

git config --global pack.packsizelimit 5g

Allerdings gilt diese Einstellung nicht sofort, stattdessen muss für ein Repack gesorgt werden:

git repack -Ad --max-pack-size=5g

Anschließend kann die Größe der Packs kontrolliert werden:

ls -lh .git/objects/pack

Allerdings sollte beachtet werden, das die Option grundsätzlich nur in Ausnahmefällen sinnvoll ist:

Note that this option is rarely useful, and may result in a larger total on-disk size (because Git will not store deltas between packs) and worse runtime performance (object lookup within multiple packs is slower than a single pack, and optimizations like reachability bitmaps cannot cope with multiple packs).

Probleme mit dem Git-Index beheben

Wer beim Arbeiten mit Git, z.B. beim Versuch einen Commit zu erstellen, folgende Meldung erhält:

fatal: unknown index entry format 0xb4d90000

ist damit konfrontiert das der Index des Git-Repositories Inkonsistenzen aufweist. In diesem Fall hilft es den Index zu löschen:

rm -f .git/index
git reset

Danach können wieder Dateien zum Index hinzugefügt werden und anschließend darauf aufbauende Operationen, wie Commits und ähnliches vorgenommen werden.

Dateien automatisch einzeln einem Git-Repository hinzufügen

Manchmal gibt es sehr spezielle Anforderungen, bei denen sich keine vorgefertigte Lösung findet. In meinem Fall war es die Anforderung eine Menge an Dateien jeweils einzeln einem Git-Repository hinzuzufügen. Herausgekommen ist ein kleines Bash-Skript:

#!/bin/bash

IFS=$'\n'; set -f

for f in $(find . -not -path '*/\.*' -type f); 
do 

  echo "$f";
  git add "$f"
  git commit -m "Add file $f"
  
done

unset IFS; set +f

Das Skript wird im entsprechenden Pfad hinterlegt und sucht anschließend nach allen Dateien, inklusive Unterordnern. Jede gefundene Datei wird anschließend einzeln dem Git-Repository hinzugefügt und anschließend ein Commit für diese Datei erzeugt.

Standard-Editor für Git setzen

Wenn das Versionsverwaltungsystem Git im Terminal bzw. auf der Konsole genutzt wird, so wird unter anderem im Falle des Befehls:

git commit

ein Editor geöffnet (in diesem Fall, zur Eingabe der Commit-Nachricht). Der betreffende Editor wird durch die Git-Konfiguration bestimmt. Innerhalb der Konfiguration definiert der Parameter core.editor den zu nutzenden Editor. Um einen Editor zu setzen, z.B. nano muss folgender Befehl genutzt werden:

git config --global core.editor "nano"

Damit wird der Editor nano in der globalen Git-Konfiguration hinterlegt und fortan als Standard-Editor für Git im Terminal genutzt.

SVN-Begrifflichkeiten

Wenn man von einem anderen Version Control System auf SVN wechselt bzw. zum ersten Mal ein VCS benutzt so wird man über einige neue Begriffe stolpern welche ich hier erklären möchte.

Repository
Das Repository bezeichnet das Archiv der Quelltexte (oder was auch immer man mittels SVN verwaltet). In dem Repository befinden sich sämtliche Revisionen des Projektes.

trunk, branch und tag
In einem SVN Repository gibt es drei Verzeichnisse names trunk, branch und tag. Im Verzeichnis trunk befindet sich die aktuelle Entwicklungszweig. Das branch Verzeichnis enthält Abspaltungen z.B. um größere Änderungen zu testen. Möchte man solche Änderung machen erzeugt man aus dem trunk einen neuen Branch. Im tag Verzeichnis können die Releaseversionen „gelagert“ werden.

Revision
Eine Revision bezeichnet die Version des Repostiories bzw. einer Datei in ebend diesem. Wenn das Repository z.B. die Revision 53 hat und man fügt eine neue bzw. ändert eine bestehende Datei des Repository so steigt deren Revision um 1. Die neue Revision ist dann 54.

Checkout
Im Gegensatz zu VC Systemen wie Visual SourceSafe bezeichnet ein Checkout bei SVN das holen einer Arbeitskopie des Repository vom Server.

Lock
Ein Lock benötigt man dann wenn man eine Datei bearbeiten möchte. Dadurch wird die Datei gesperrt, so das andere Nutzer sie nicht bearbeiten können (je nach Einstellung). Möchte man die bearbeitete Datei nun zurück in Reposity bringen so macht man ein Commit.

Commit
Mit einem Commit werden die veränderten Dateien wieder ins Repository hochgeladen.

Weitere Informationen unter:
http://de.wikipedia.org/wiki/Subversion_(Software)