Aus dem Leben eines Szlauszafs (Entries tagged as git)

Tips und Tricks für den Umgang mit git

thh@inter.net (Thomas Hochstein) — Wed, 12 Jan 2011 17:30:00 +0100

Bei meiner Arbeit mit git stehe ich immer wieder vor der Frage, ob man dieses oder jenes damit nicht einfach machen können müßte. Meistens lautet die Antwort auf diese Frage “ja”, aber teilweise muß man schon etwas googeln, um diese Antwort zu finden. Daher möchte ich ab und an kleine ergoogelte Wissensschnippsel mit der Leserschaft teilen; vielleicht steht ja noch einmal jemand anderes vor demelben Problem (und überdies sind deutschsprachige Informationen zu git nicht so wirklich umfänglich vorhanden).

Git über SSH und mehrere SSH-Keys pro Host

Mehr eine allgemeine SSH-Frage, aber da sie sich mir im Zusammenhang mit git gestellt hat ...

Ein beliebter Zugriffsweg auf Git-Repositories ist der über SSH, insbesondere, wenn es auch um einen schreibenden Zugang geht und man diesen authentifizieren will. Zu diesem Zweck kann man sich den passenden SSH-Schlüssel für den Zugriff auf das Git-Repository über die SSH-Konfiguration definieren, bspw. durch einen Eintrag in ~/.ssh/config wie den folgenden:

Host git.example.org
Port 2022
IdentityFile ~/.ssh/gitkey

SSH-Zugriffe auf den Server “git.example.org” erfolgen also auf Port 2022 (statt 22) und unter Verwendung des Schlüssels “gitkey”. Der Git-Zugriff via SSH berücksichtigt diese Einstellungen dann automatisch.

Was aber tun, wenn man von demselben Client mit mehreren verschiedenen SSH-Schlüsseln auf denselben Server zugreifen muß, wie es insbesondere bei der Verwendung von Tools wie gitosis auf der Serverseite vorkommen kann? Dieselbe Frage stellt sich natürlich, wenn man sich neben dem Zugriff auf ein Git-Repository auch ganz normal per SSH auf dem Server einloggen können will. Auf die obige Art und Weise läßt sich nur ein Key für den Zugriff auf “git.example.org” vordefinieren - und will man wirklich immer einen abweichenden Schlüssel per Option angeben? Eine Lösung wäre die Vergabe von weiteren CNAMEs im DNS für git.example.org, aber das skaliert auf die Dauer auch nicht.

Die einfachste Lösung dafür bieten Aliase direkt in der SSH-Konfiguration, wie das Git-Wiki empfiehlt:

Host private.example.com
        User myname
        Hostname git.example.com
        IdentityFile ~/.ssh/private-identity
Host public.example.com
        User groupname
        Hostname git.example.com
        IdentityFile ~/.ssh/public-identity

Auf diese Art und Weise kann man denselben Server mit zwei verschiedenen Konfigurationen ansprechen.

Übernahme einer einzelnen Datei aus einem anderen Branch

Alle Änderungen aus einem anderen Entwicklungszweig zu übernehmen ist einfach und geht per merge; nur bestimmte Änderungen (commits) zu übernehmen funktioniert via cherry-pick. (Warum auch immer das Rosinenpicken der Deutschen dem Angelsachsen ein Picken nach Kirschen ist ...) Aber wie kann man eine bestimmte Datei - also alle Änderungen, aber nur die in einer bestimmten Datei - aus einem anderen Branch übernehmen?

Zu dieser Frage hat Jason Rudolph die passende Antwort: das geht mit git-checkout, und zwar in der Form git checkout $branch $path. Nehmen wir an, ich möchte die Fassung der Datei “README” aus dem Branch “test” in meinen Branch “master” übernehmen, aber eben nur diese Datei in genau dem Zustand, den sie im “test”-Branch hat. Das geht dann folgendermaßen:

git checkout master
git checkout test README
git commit -m ‘Imported README from test branch’

Genauso funktioniert das natürlich mit mehreren Dateien:

git checkout test README doc/explanation.txt doc/TODO

Voilà. Soviel für heute.

Mantis: Git-Integration - ein steiniger Weg

thh@inter.net (Thomas Hochstein) — Sat, 15 May 2010 10:46:00 +0200

Sehr praktisch ist es bei einem Bugtracker, wenn er mit dem verwendeten Versions-/Sourcecode-Verwaltungssystem (SCM-System, source code management) interagieren kann, Änderungen im Code, die - laut Kommentar (Commit-Message) - einen bestimmten Fehler beheben, also direkt auch dazu führen, daß der entsprechende Fehlerbericht (Bugreport) als erledigt gekennzeichnet wird. Man kennt dieses Verhalten - bspw. - vom Debian-Bugtracker.

Grundsätzlich ist das auch schon immer mit Mantis möglich; allerdings war die bisher vorhandene Unterstützung rudimentär und primär auf SVN abgestellt; sie wurde auch in der aktuellen Entwicklungsversion 1.3 entfernt. Seit Anfang 2009 gibt es nämlich von einem der Mantis-Entwickler, John Reese, ein Plugin namens Source Control Integration, das sich beim Bugtracker für Mantis selbst bereits seit Monaten im Echtbetrieb bewährt hat. Es liefert ein Framework für die Anbindung beliebiger Versionsverwaltungssysteme, und fertige Plugins für die Anbindung an git via GitHub oder GitWeb und an SVN via SourceForge oder WebSVN sind direkt dabei.

Leider ist auch hier die Dokumentation der schwache Punkt. Eine solche fehlt nämlich bisher völlig; einen Einstieg liefert einzig ein Blogbeitrag vom 07.01.2009, der die Vorgehensweise beschreibt. Weitere Blogbeiträge (von März und Oktober 2009) umreißen die technischen Grundlagen und beschreiben den Einsatz für Subversion, helfen aber ansonsten auch nicht wirklich weiter.

Ich habe mir die Vorgehensweise bisher folgendermaßen zusammengereimt:

Download der nötigen Plugins (Meta Programming, Source Control Integration und - in meinem Fall - Gitweb Integration). Fertige Lösungen scheint es dafür nicht zu geben, die Plugins sind offenbar aus dem Git-Repository des Entwicklers auszuchecken (dabei finden sich die vorgenannten Plugins für die Anbindung an git und SVN im selben Repository wie Source Control Integration). Danach gehören die entsprechenden Verzeichnisse ins Mantis-Plugin-Verzeichnis, das man in Mantis auch unter dem Punkt [Manage] (http://host.domain.example/mantis/manage_overview_page.php) angezeigt findet.
UPDATE vom 30.10.2012: Das Git-Repository des Entwicklers ist offenbar nicht mehr aktuell bzw. liegt jetzt bei Github: Source Control Integration
Das Plugin Meta Programming sollte bei Mantis 1.2.x bereits mit dabei sein und muss daher nicht mehr installiert werden..

Anschließend sind die Plugins - in der richtigen Reihenfolge - unter [Manage Plugins] (http://host.domain.example/mantis/manage_plugin_page.php) zu installieren.

Danach kann das Plugin, wie im genannten Blogbeitrag beschrieben, konfiguriert, ein Repository definiert und dieses dann eingelesen werden.

Letzteres hat bei mir auf Anhieb zu einer eleganten Fehlermeldung geführt:

APPLICATION ERROR #401

Database query failed. Error received from database was #1048: Column ‘author’ cannot be null for the query: INSERT INTO mantis_plugin_Source_changeset_table ( repo_id, revision, parent, branch, user_id,timestamp, author, message, info, ported, author_email, committer, committer_email, committer_id) VALUES ( ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ? ).

Deren Ursache liegt darin, daß das Plugin die Ausgabe von GitWeb nicht richtig parsen kann. In meinem Fall war der Übeltäter die in GitWeb aktivierte Avatar-Funktion; einen Patch dafür findet man im Bugtracker des Entwicklers.

UPDATE: Auch mit der GitWeb-Version 1.7.1 gibt es Schwierigkeiten, namentlich, wenn und weil jetzt die Möglichkeit der Suche nach Commits des jeweiligen Autors aktiviert ist. Wer einen Patch dazu sucht, findet diesen an der bereits genannten Stelle.

UPDATE vom 30.10.2012: Der Bugtracker des Entwicklers ist auf eine statische Archiv-Version zurückgesetzt und enthält den Patch daher nicht mehr. Er findet sich dafür hier in den Kommentaren. - Die aktuelle Version im Github-Repository des Entwicklers scheint ihn aber im wesentlichen bereits eingebaut zu haben.

Danach funktionierte der Import aber und lief wie am Schnürchen.

Jetzt möchte man das nur noch automatisieren; die entsprechende Angabe im genannten Blogbeitrag ...

For Gitweb, SourceForge, or WebSVN integration, find your repositorys ID, and setup a cronjob (or something equivalent) to run "curl http://yoururl.xyz/mantisbt/plugin.php?page=Source/repo_import_latest&id=XX"

... ist aber leider unzutreffend, denn die entsprechende Seite kann nur durch einen - eingeloggten - Admin aufgerufen werden. Korrekt ist vielmehr der Aufruf von http://host.domain.example/mantis/plugin.php?page=Source/import&id=XX; das ist die vorgesehene API dafür. Der entsprechende Aufruf kann per Cronjob, aber sicherlich auch als Post-Update-Hook in git verwirklicht werden:

curl ‘http://host.domain.example/mantis/plugin.php?page=Source/import&id=XX’ > /dev/null

Über weitere Erfahrungsberichte zu diesem Thema würde ich mich übrigens freuen.

msysgit mit PLink, Pageant und SSH

thh@inter.net (Thomas Hochstein) — Mon, 12 Apr 2010 23:02:00 +0200

Systemeigenschaften -> Erweitert

Was mich bei meiner Nutzung von git unter Windows noch etwas störte war vor allem, daß ich für den Zugriff auf externe Repositories bisher auf TortoiseGit angewiesen war, weil Git on Windows (msysgit) nicht recht zur Kommunikation über SSH bereit war; angeblich wurde nie der passende Schlüssel gefunden, obwohl eigentlich PLink und Pageant aus dem Putty-Paket installiert waren und mit TortoiseGit ihre Arbeit auch prima taten. Die Google-Recherche führte mich dann allerdings zu einem passenden Beitrag, und nach einigem ausprobieren kann ich bestätigen, daß die dort genannte Lösung funktioniert:

Git on Windows (msysgit) installieren
Putty installieren (soweit erforderlich)
Pageant konfigurieren (soweit war ich schon)
Umgebungsvariable GIT_SSH auf PLink setzen
GitBash und/oder GitGui neu starten (!)

Danach funktionierte die Sache bei mir wunderbar.

Umgebungsvariablen

Die Umgebungsvariable GIT_SSH setzt man unter Windows XP in den “Systemeigenschaften” (Rechtsklick auf “Arbeitsplatz” oder “My Computer” und dann “Eigenschaften”) auf der Registerkarte “Erweitert” unter dem Button “Umgebungsvariablen” unter “Systemvariablen”. Ein beherzter Klick auf “Neu” fördert ein Eingabefeld zutage, in dem man nunmehr “GIT_SSH” und den kompletten Pfad zur Datei “PLink.exe” - bspw. “C:\Programme\PuTTY\plink.exe” - eingibt. Neustart von msysgit nicht vergessen!

Voilà! Bei mir funktionierte die SSH-Übertragung dann ohne jedes Problem.

Sprachauswahl bei Git on Windows (msysgit)

thh@inter.net (Thomas Hochstein) — Fri, 09 Apr 2010 07:21:00 +0200

Wie ich bereits im Februar beschrieben habe, benutze ich unter Windows msysgit bzw. “Git on Windows”. Die GUI-Variante ermöglicht die meisten denkbaren Aktionen in sehr bequemer Weise durchzuführen; sie krankt allerdings - aus meiner Sicht - arg an ihrer Übersetzung, die sämtliche Menüeinträge und damit natürlich auch Fachbegriffe umfaßt und manchmal zu Rätselraten führt, was genau gemeint sein mag. “Zweig” ist ja noch klar, “Zusammenführen” für “Merge” auch, aber das “Version” für “Commit” steht erschließt sich nicht sofort. Und Menüpunkte unterhalb von “Zweig” wie “Erstellen”, “Umstellen” oder “Zurücksetzen” sind auch alles andere als klar - “Erstellen” ist ohne Frage “Create”, aber “Umstellen”? Gut, man kann vielleicht noch darauf kommen, daß das für “Checkout / Switch” steht ... aber bedeutet “Zurücksetzen” jetzt “Reset” oder “Rebase”? Usw. usf. ... Da wäre doch eine englische Bedienungsoberfläche eine tolle Sache, da weiß man wenigstens, welche Funktion jeweils gemeint ist, und kann die dann ggf. nachschlagen.

Es scheint leider derzeit noch keine Möglichkeit zur manuellen Auswahl einer Sprache zu geben, auch nicht durch Setzen von Environment-Variablen (zumindest hat Google sich insoweit ausgeschwiegen); es wird automatisch auf die Systemsprache abgehoben. Eine Lösung gibt es dennoch - wenn man dafür sorgt, daß die Programme ihre deutschen Sprachdateien nicht mehr finden, fallen sie auf den englischen Default zurück, und das ist ja genau das, was wir wollen.

Die Sprachdateien liegen in %ProgramFiles%\Git\share\git-gui\lib\msgs bzw. %ProgramFiles%\Git\share\gitk\lib\msgs; dort muß jeweils nur die Datei “de.msg” entfernt - oder umbenannt - werden, und alles wird gut (bzw. in diesem Fall englischsprachig). Nach Updates ist dieser Schritt natürlich erneut erforderlich.

git archive

thh@inter.net (Thomas Hochstein) — Sat, 27 Feb 2010 18:52:00 +0100

Ein weiteres nettes Feature von git sind die Möglichkeiten, die git archive bietet. So läßt sich der Inhalt eines git-Repositories leicht in ein tar-File packen, bspw. für ein Release.

Voraussetzung dafür ist beim Zugriff über git-daemon, daß der entsprechende Service aktiviert ist; für das Debian-Paket bedeutet das die Erweiterung des Aufrufs in /etc/sv/git-daemon/run um den Parameter “--enable=upload-archive”.

Dann aber kann mit einem Aufruf wie

git archive --format=tar --remote=git://git.domain.example/$REPO.git --prefix=$PREFIX/ $TAG | gzip > $REPO.tar.gz

aus dem Repository $REPO.git dessen Inhalt bei Commit (oder an der Spitze des Branches, oder an dem Tag) $TAG in eine .tar.gz-Datei gepackt werden, wobei die Dateien ein $PREFIX vorangestellt bekommen.

git archive --format=tar --remote=git://git.domain.example/myprog.git --prefix=myprog-2.17/ 2.17 | gzip > myprog-2.17.tar.gz

erzeugt also aus dem Repository myprog.git in der mit “2.17” getaggten Version eine Datei myprog-2.17.tar.gz, die alle im Repository enthaltenen Dateien mit dem Verzeichnis-Präfix “myprog-2.17/” enthält.

Das ganze läßt sich noch etwas aufpeppen, wenn man bspw. bestimmte Dateien (.gitignore, ...) aus dem Repository nicht im Tarball haben möchte und/oder noch andere Änderungen vornehmen will, wie bspw. die Erzeugung eines README aus der eingebetteten POD-Dokumentation:

#! /bin/bash
# do a release of myprog
# $1: version number

# make tempdir
tempdir=`mktemp -td myprog-XXXXX`

git archive --format=tar --remote=git://git.domain.example/myprog.git --prefix=myprog-$1/ $1 | (cd $tempdir && tar xf -)

cd $tempdir/myprog-$1/
pod2text -l myprog.pl README
rm .gitignore

cd $tempdir
tar -czf /var/www/myprog/download/myprog-$1.tar.gz myprog-$1/
rm -r $tempdir

Und schließlich kann man auf diese Weise auch nur eine einzelne Datei aus dem Repository extrahieren:

git archive --format=tar --remote=git://git.domain.example/repository.git master beispiel.txt | tar xf -

extrahiert die Datei beispiel.txt aus der Spitze des Branches master des Repositorys repository.git.

Ich finde das alles ausgesprochen praktisch.

Was mir an git gefällt

thh@inter.net (Thomas Hochstein) — Wed, 24 Feb 2010 22:33:00 +0100

Nachdem ich mich jetzt bereits einige Wochen mit git auseinandersetze, ist es vielleicht einmal Zeit für ein Fazit. Ich mag mir kein fachkundiges Urteil über git erlauben; dazu fehlt mir der wirkliche Vergleich mit anderen Versionsverwaltungssystemen und die Erfahrung mit (gemeinsamer) Softwareentwicklung, und letztlich auch der wirklich “fortgeschrittene” Umgang mit git. Ich denke aber, daß ich - obschon ich git bisher “solo” nutze, also zu seinen Stärken und Schwächen bei der Zusammenarbeit selbst nichts sagen kann - durchaus einige Punkte benennen kann, die mir an git gut gefallen.

Da wäre auf den ersten Blick bereits die Verzeichnisstruktur: wo SVN mich mit trunk, tags und branches verwirrt, gibt es bei git ein Verzeichnis .git, und das war’s.

Auch zunächst eher eine Äußerlichkeit, aber sehr bequem, ist die Möglichkeit, mit git “offline” zu arbeiten. Bei git wird die Arbeitskopie nicht aus einem zentralen Repository ausgecheckt; vielmehr wird das zentrale Repository im Normalfall komplett kopiert und steht mir dann auch offline mit der gesamten Versionsgeschichte zur Verfügung. Das ermöglicht es überdies, neben einem “offiziellen” Repository - das im Netz steht - beliebig viele “inoffizielle” Repositories vorzuhalten. Änderungen kann ich so zunächst nur in meiner Kopie des Repositories vornehmen (und sie ggf. auf andere eigene Rechner spiegeln und auch mit anderen Entwicklern austauschen) und sie erst dann veröffentlichen, wenn ich sie für veröffentlichungsreif halte. So kann ich bspw. immer nur bestimmte Zweige meines Entwicklungsrepositories in ein öffentliches Repository übertragen und andere, an denen ich noch bastele, nicht veröffentlichen.

Das problemlose Anlegen von Kopien (Zweigen, branches) ist aus meiner Sicht ein weiterer Vorteil; ein Entwicklungszweig (branch) ist trivial und schnell angelegt und ebenso schnell auch wieder entfernt. Das ermöglich ein schmerzloses Ausprobieren von Änderungen jeder Art; man kann für jede Idee einfach einmal schnell einen neuen Zweig anlegen, sie ausprobieren und dann ggf. verwerfen oder auf Eis legen kann - oder in die “eigentliche” Entwicklungslinie übernehmen. Auch lassen sich so verschiedene Ideen einfach in verschiedenen Branches entwickeln und dann jederzeit direkt in den Hauptzweig übernehmen, oder man kann sie erst noch etwas “köcheln” lassen; daneben können verschiedene Entwicklungsstränge bspw. für eine geplante neue Version und für Bugfixes älterer Versionen nebeneinander laufen.

Ergänzend dazu fasziniert mich die Möglichkeit, meine Commits nachträglich nachzubessern und neu zu sortieren. Die Möglichkeit fraktionierter Commits hatte ich bereits angesprochen; außerdem kann ich jederzeit per interaktivem rebase einzelne Commits zusammenfassen. Oder ich setze einfach nur den Index auf eine alte Version zurück, so daß ich dann die Änderungen in der aktuellen Arbeitskopie gegenüber diesem alten Zustand neu einchecken kann, auch in einzelnen Teilen. In diese Reihe gehört auch die Möglichkeit, mein lokales Repository - oder einzelne Entwicklungszweige darin - immer wieder neu auf den aktuellen Stand des “offiziellen” Repositories - oder des Hauptentwicklungszweiges - aufsetzen zu lassen. All das ermöglicht es - auch zusammen mit dem leichten Anlegen neuer branches - auf der einen Seite, nahezu beliebig “herumzuspielen” und dabei dem Motto “Commit early, commit often” zu folgen, auf der anderern Seite aber später, wenn das Feature gereift ist, eine logische Abfolge von einzelnen Patches zu committen, die die ganzen Sackgassen und Fehlversuche auslässt und möglichst einfach nachzuvollziehen ist.

Um ein paar Beispiele für die Vorteile dieser Arbeitsweise zu nennen:

Ich kann zum Beispiel während der laufenden Entwicklung jeden Entwicklungszweig (branch) immer wieder periodisch neu auf den aktuellen Stand des Hauptzweigs (master branch) aufsetzen lassen (rebase); wenn die Entwicklung eines bestimmten Features dann reif ist, kann ich sie in den Hauptzweig übernehmen und habe dann nur genau diese Änderungen in der Versionsverwaltung stehen, und zwar ausgehend vom aktuellen Stand des Hauptzweigs. Statt rebase könnte ich natürlich auch merge benutzen, dann habe ich aber eine Unzahl von für das Verständnis überzähligen Commits in der Versionsgeschichte stehen.

Nehmen wir an, ich arbeite an einem bestimmten Feature und committe Änderungen oft und zeitnah (um sie ggf. wieder zurücknehmen zu können, wenn sich der Weg als Irrweg erweist). Irgendwann bin ich dann mit dem Sachstand zufrieden und halte das Feature für reif genug für das nächste Release. Jetzt könnte ich den Entwicklungszweig einfach in den Hauptzweig mergen; dann steht aber das gesamte hin und her in der Versionsgeschichte, was sie auf die Dauer eher unübersichtlich macht. Ich kann aber auch durch interaktives rebase und/oder durch ein reset zunächst den Entwicklungszweig neu zusammenstellen und entscheiden, in wie viele Commits in welcher Reihenfolge ich meine diversen Änderungen aufgeteilt haben möchte. Ich schreibe quasi rückblickend die Versionsgeschichte nachvollziehbar und ordentlich neu und merge dann eine logische Abfolge von einzelnen Schritten in den Hauptzweig. Das sieht nicht nur eleganter aus, es ist auch leichter verständlich.

Andersherum kann ich vorgenommene Änderungen auch sukzessive in mehreren Commits in die Versionsverwaltung schreiben. Angenommen, ich habe eine Website in einem git-Repository liegen und nehme umfangreiche Änderungen und Ergänzungen an einer Webseite vor. Bei dieser Gelegenheit fallen mir auch einige Rechtschreibfehler im bereits vorhandenen Text auf. Jetzt könnte ich entweder erst meine Änderungen und Ergänzungen abschließen, sie committen und dann in einem zweiten Schritt die Rechtschreibfehler beheben (wenn ich das nicht bis dahin vergessen habe). Oder ich behebe die Rechtschreibfehler nebenbei mit und committe sie zusammen mit den Änderungen; aber dann wird die commit message ein Gemischtwarenladen und ich kann v.a. meine Änderungen nicht isoliert reverten. Mit git kann ich die an der Arbeitskopie vorgenommenen Veränderungen stückchenweise committen: bspw. erst isoliert die Rechtschreibfehler, und dann - getrennt davon - die zeitgleich vorgenommenen Änderungen und Ergänzungen. Danach habe ich zwei getrennte Commits, die zwei logisch verschiedene Vorgänge getrennt wiedergeben und die auch getrennt zurückgenommen werden können.

Ich halte das - mit Vorsicht genutzt - für ein sehr interessantes Arbeitswerkzeug. “Mit Vorsicht genutzt” deshalb, weil es natürlich fatal ist, die Versionsgeschichte bereits veröffentlichter branches umzuschreiben ... deshalb sollte man entweder nur die Entwicklungszweige öffentlich zugänglich machen, die man auch unverändert so stehenlassen möchte, oder wenigstens klar kommunizieren, welche Entwicklungszweige “work in progress” sind und keinesfalls für eigene Entwicklungszwecke gepullt werden sollen.

Git unter Windows

thh@inter.net (Thomas Hochstein) — Sun, 21 Feb 2010 17:21:00 +0100

Bereits Anfang Januar hatte ich von Git berichtet und danach geschildert, wie man Git-Repositories mit gitosis und gitweb, offen wie auch paßwortgeschützt, aufsetzen kann. Seitdem habe ich eine ganze Reihe Projekte in Git-Repositories eingecheckt und gewöhne mich immer mehr an die Arbeit mit Git, zumeist allerdings unter Windows (weil ich auf Laptop wie auch Desktoprechnern unter Windows arbeite).

Dazu verwende ich TortoiseGit, eine Portierung des recht bekannten (und gelobten) TortoiseSVN, und zugleich Git on Windows (msysgit), das ohnehin als Voraussetzung für die Verwendung von TortoiseGit heruntergeladen werden muß. Beide ergänzen sich, wie ich finde, recht gut. TortoiseGit ermöglicht eine einfache Definition des Remote Repository und elegante Lösungen für die Darstellung von Diffs und Merges, ganz zu schweigen von der grafischen Darstellung des Dateistatus im Explorer; die Git-Bash und GitTk aus msysgit hingegen sind m.E. optimal für Branching und (inkrementielle) Commits sowie für die Darstellung der History. Störend allenfalls, daß die Tools teilweise - trotz der einigermaßen großzügigen Ausstattung an Rechenleistung und RAM - arg langsam wirken. Insgesamt aber, wie ich finde, eine sehr bequeme Lösung.

INN-Funktionsweise: Steuernachrichten und Filter

thh@inter.net (Thomas Hochstein) — Sun, 17 Jan 2010 17:06:00 +0100

Der Urlaub neigt sich endgültig seinem Ende zu, und - leider - ist die Todo-Liste, insbesondere hinsichtlich angedachter größerer Projekte, die man abends oder am Wochenende (zumindest bei meiner derzeitigen zeitlichen Belastung) nicht sinnvoll angehen kann, nicht merklich geschrumpft. Stattdessen habe ich mich (ungeplant) auf die Datensammlung zu Usenet-Hierarchien und danach dann auf den Umgang mit git konzentriert und am Ende eine ganze Reihe Dinge umgesetzt, die auf der ToDo-Liste eigentlich gar nicht vorkamen.

Nachdem Newsserver in den letzten Wochen eine so große Rolle gespielt haben ist es jetzt zum Abschluss nur recht und billig, wenn ich (nach mehrjähriger Pause) meine Seite zur Funktionsweise des INN endlich um die noch fehlenden Teile ergänze; umso mehr, als ich meine Webseiten mittlerweile in ein git-Repository eingecheckt habe und daher auch den Umgang damit üben kann, insbesondere, was fraktionierte Commits betrifft. Das ist eine sehr nette Sache: man nimmt eine Reihe unterschiedlicher Änderungen vor, die nichts miteinander zu tun haben - bspw. eine Ergänzung der INN-Beschreibung auf der einen Seite und Richtigstellungen/Tippfehlerkorrekturen, über die man zufällig stolpert, auf der anderen -, und kann diese Änderungen aber selektiv committen, bspw. zuerst nur die Ergänzungen, dann die Änderungen, dann die Rechtschreibfehler. Das macht die Commits übersichtlicher und ggf. auch leichter zu reverten, weil man nur logisch zusammengehörendes auch zusammen committet, ohne daß man beim Editieren darauf achten müßte.

Ich kann also hiermit verkünden, daß ich die Abschnitte über Steuernachrichten (control.ctl), Filter und Reader-Authentifizierung sowie eine recht umfangreiche Linksammlung ergänzt habe. Fehlen nur noch Erläuterungen zum Expire, aber das muß ich erst einmal selbst verstehen.

Update 2010-01-26: Inzwischen steht auch die Erläuterung zum Expire online. Die Seite ist damit - endlich! - fast fünf Jahre nach ihrer ersten Erstellung komplettiert. Ich hoffe, sie hilft dem einen oder anderen (vermißt wurden die fehlenden Teile allerdings offensichtlich nicht, wenn man nach dem erhaltenen Feedback über die Jahre geht ...).

gitweb mit Passwortschutz

thh@inter.net (Thomas Hochstein) — Sat, 16 Jan 2010 20:04:00 +0100

gitweb ist, wie vorgestern beschrieben, eine schöne Sache - aber nicht immer will man seine Repositories jedermann zugänglich machen. Schön wäre es doch, wenn man die Möglichkeit hätte, auch den Zugriff auf gitweb an eine Anmeldung zu koppeln und so nur für befugte Benutzer zu erlauben. Eine Möglichkeit dazu will ich nachstehend schildern, orientiert an einem Beitrag im Blog von Leho Kraav.

Weitere, vielleicht hilfreiche Anregungen dazu kann man ergoogeln, bspw.

u.a.

Voraussetzung dafür ist eine ausreichend neue Version von gitweb; die in Debian Lenny verfügbare Version 1.5.6.5 genügt nicht. Sie kann allerdings gepatcht werden (die Änderung ist minimal):

--- /usr/lib/cgi-bin/gitweb.cgi.OLD 2010-01-14 16:49:44.000000000 +0100
+++ /usr/lib/cgi-bin/gitweb.cgi     2010-01-15 15:30:40.975350737 +0100
@@ -86,6 +86,11 @@
 # (only effective if this variable evaluates to true)
 our $export_ok = "";
 
+# show repository only if this subroutine returns true
+# when given the path to the project, for example:
+#    sub { return -e "$_[0]/git-daemon-export-ok"; }
+our $export_auth_hook = undef;
+
 # only allow viewing of repositories also shown on the overview page
 our $strict_export = "";
 
@@ -353,7 +358,8 @@
 sub check_export_ok {
        my ($dir) = @_;
        return (check_head_link($dir) &&
-               (!$export_ok || -e "$dir/$export_ok"));
+               (!$export_ok || -e "$dir/$export_ok") &&
+                (!$export_auth_hook || $export_auth_hook->($dir)));
 }
 
 # process alternate names for backward compatibility

Das vorausgesetzt, genügt es, die gitweb.conf folgendermaßen zu erweitern:

# HTTP Basic Auth
$gitosis_conf = '/home/gitosis/.gitosis.conf';
$username = $cgi->remote_user;
$export_auth_hook = sub {
  my $projectdir = shift;
  if($projectdir =~ (/(.*?)\.git/)) {
    #my $projectname = basename($1);
    my $projectname = $1;
    $projectname =~ s/$projectroot\/?//;
    open FILE, $gitosis_conf or die 'Could not open gitosis config file. Please make sure that $gitosis_conf is set properly';
    my $project_match = 0;
    my $user_match = 0;
    while(<FILE>) {
      if($_ =~ /^\s*members\s*\=\s*(?:.*?\s)*$username(?:\s+|$)/) {$user_match = 1;}
      if($_ =~ /^\s*(read|writ)able\s*\=\s*(?:.*?\s)*$projectname(?:\s+|$)/) {$project_match = 1;}
      if($project_match && $user_match) {
         return 1;
      }
      if($_ =~ /\[group/) {
          $project_match = $user_match = 0;
      }
    }
  }
  return 0;
};

Dann muß noch die Apache-Konfiguration passend erweitert werden, um HTTP-Basic-Authentication für das entsprechende Verzeichnis zu machen:

<Location />
 AuthType Basic
 AuthName "git.host.example"
 AuthUserFile /home/gitosis/gitosis/ht.passwd
 Require valid-user
</Location>

Pfade müssen, wie üblich, entsprechend angepaßt werden.

Und schließlich müssen für die in der gitosis.conf definierten Benutzer - jedenfalls diejenigen, die auch Webzugriff haben sollen - Paßworte in der /home/gitosis/gitosis/ht.passwd angelegt werden. Dazu wird wie gewohnt htpasswd bzw. htpasswd2 aufgerufen.

Voilá!

Git-Repositories mit gitosis und gitweb (Debian Lenny)

thh@inter.net (Thomas Hochstein) — Thu, 14 Jan 2010 18:41:00 +0100

Wie ich bereits schrieb, habe ich mich in den letzten Tagen etwas näher mit dem Versionskontrollsystem (VCS, oder auch SCM für “Source-Code-Management”) git beschäftigt. Das macht natürlich nur bedingt Spaß - und Sinn -, wenn die Repositories nur auf dem heimischen Rechner liegen; um wirklich universal auf sie zugreifen zu können und auch die Zusammenarbeit mit anderen zu ermöglichen, sollten die Repositories irgendwo im Netz stehen, und eine nette Weboberfläche, die auch einen Zugriff über den Browser - ohne weitere Software - ermöglicht, um den aktuellen Stand der Bearbeitung zu sehen, Commits zu prüfen und ggf. einen Snapshot zu ziehen, wäre auch nicht schlecht.

Um mir die Anlage von Repositories und das Zusammenspiel mit den anderen Komponenten zu erleichtern und auch für erweiterte Anforderungen wie verschiedene Zugriffsrechte für die jeweiligen Repositories gerüstet zu sein, habe ich mich für die Verwaltung der Repositories für gitosis entschieden; als Weboberfläche will ich gitweb nutzen, und für den Zugriff via git dann git-daemon. Installiert habe ich dazu die jeweiligen Pakete aus Debian Lenny bzw. den Debian-Backports.

Die Installation und Konfiguration habe ich folgendermaßen durchgeführt:

1. gitosis

a) Vorüberlegungen

gitosis bietet die Möglichkeit, Benutzer und Repositories zu konfigurieren. Die entsprechenden Repositories werden dann angelegt; für jedes kann gesondert festgelegt werden, welcher Benutzer - lesen oder schreibend - darauf zugreifen kann. Die Zugriffe erfolgen über (git-über-)SSH; jeder Benutzer muß dazu seinen öffentlichen SSH-Schlüssel hinterlegen. Er verbindet sich dann unter dem Benutzernamen (Useraccount) “gitosis” per SSH mit dem Server, auf dem das Repository liegt; gitosis prüft dann, welcher SSH-Schlüssel für die Verbindung übergeben wird und identifiziert auf diese Weise den Benutzer.

Die Konfiguration von gitosis erfolgt gleichfalls über ein git-Repository, das zunächst ausgecheckt wird; danach kann man die Konfiguration ändern und bspw. neue Repositories und Benutzer anlegen (und im Falle eines neuen Benutzers auch dessen öffentlichen SSH-Schlüssel speichern) und die Änderungen committen. Beim Commit paßt gitosis über entsprechende Hooks die Konfiguration an. Das Konfigurations-Repository kann entweder auf denselben Rechner ausgecheckt werden oder auf einen beliebigen anderen Client; auch diese Verbindungen erfolgen über (git-über-)SSH, und auch dafür muß man (s)einen öffentlichen SSH-Key bei gitosis hinterlegen. Ich habe mich entschlossen, dafür einen eigenen Key anzulegen; man kann aber natürlich auch einfach (s)einen bestehenden SSH-Schlüssel verwenden.

Standardmäßig sieht das Debian-Paket von gitosis die Anlage der Repositories in /srv/gitosis an; das paßt allerdings nicht zur Partitionierung meines Mietservers, der - historisch und aus dem Image des Anbieters bedingt - platzmäßig eher knapp kalkulierte Partitionen bietet und den gesamten restlichen Plattenplatz in /home eingehängt hat. Daher möchte ich die Repositories auch in /home/gitosis liegen haben.

b) Installation (der Debian-Pakete) und Inbetriebnahme

Zunächst sind git selbst und gitosis zu installieren:

aptitude install git-core git-doc gitosis

Danach lege ich ein Home-Verzeichnis für gitosis in /home an, lösche /srv/gitosis und setze einen Symlink auf das Home-Verzeichnis:

mkdir /home/gitosis
chown gitosis:gitosis /home/gitosis
rmdir /srv/gitosis/
ln -s /home/gitosis /srv/gitosis

Dann ist entweder mit ssh-keygen ein neues Schlüsselpaar zu erzeugen oder der öffentliche Schlüssel eines bestehenden Schlüsselpaares in einer Datei bereitzulegen, bspw. in git-admin_rsa.pub. Den verfüttert man dann an gitosis:

sudo -H -u gitosis gitosis-init < git-admin_rsa.pub

Dann habe ich der Bequemlichkeit halber noch die Konfiguration des SSH-Clients angepaßt, um bei SSH-Verbindungen zu localhost - was in meinem Fall nur für git-über-SSH bei der Konfiguration von gitosis vorkommt - direkt den richtigen Schlüssel zu benutzen, und dazu in ~/.ssh/config folgendes eingefügt:

Host localhost
IdentityFile ~/.ssh/git-admin_rsa

Zur Konfiguration und Einrichtung der Benutzer muß das Konfigurations-Repository von gitosis jetzt erst einmal ausgecheckt werden (in meinem Falle geschieht das auf demselben Host, man kann aber natürlich auch von jedem anderen Host aus mit dem oben an gitosis übergebenen SSH-Schlüssel auf das Repository zugreifen):

git clone gitosis@localhost:gitosis-admin.git gitosis-admin

Damit wird das Repositoy in das Verzeichnis gitosis-admin ausgecheckt. Dort befindet sich dann die Datei gitosis.conf und das Verzeichnis keydir; in ersterer werden Benutzer und Repositories angelegt, in letzterem finden sich die öffentlichen SSH-Schlüssel der Benutzer.

c) Konfiguration und Einrichtung der ersten Benutzer und Repositories

Als erstes nehme ich mir die gitosis.conf vor und prüfe bzw. setze dort die globalen Einstellungen:

[gitosis]
## To override the default ~/repositories path
# repositories = repositories

## Allow gitweb to show all known repositories. If you want gitweb,
## you need either this or a [repo foo] section for each repository
## you want visible in gitweb.
gitweb = no

## Allow git-daemon to publish all known repositories. As with gitweb,
## this can be done globally or per-repository.
daemon = no

## Logging level, one of DEBUG, INFO, WARNING, ERROR, CRITICAL
loglevel = INFO

Die Optionen sind im Prinzip selbsterklärend. Ich habe mich entschieden, den Webzugriff und den Zugriff via git-daemon nicht generell freizugeben, sondern das per Repository zu steuern.

Als nächstes werden Benutzergruppen und deren Rechte festgelegt:

### groups #####---------------
[group gitosis-admin]
writable = gitosis-admin
members = admin@admin.host.example

[group friends]
writable = repo-eins projekt/projektrepo-eins
members = me@my.host.example he@his.host.example another@another.host.example

[group myself]
writable = private projekt/projektrepo-private
members = me@my.host.example

Zur Gruppe “gitosis-admin” gehört also der Benutzer, der über den SSH-Key “admin@admin.host.example” identifiziert wird; dieser hat Zugriff auf das Konfigurations-Repository “gitosis-admin”. Zur Gruppe “friends” gehören neben mir (“me@my.host.example”) auch noch zwei andere, und diese Gruppe hat Zugriff auf zwei verschiedene Repositories; zur Gruppe “myself” gehöre nur ich mit Zugriff auf zwei weitere Repositories. Statt Lese- und Schreibzugriff (“writable”) kann auch ein bloßer Lesezugriff vergeben werden.

Diese Repositories werden dann im Anschluss konfiguriert:

### repos #####----------------
[repo repo-eins]
## Oneline description of the project, mostly for gitweb.
description = Repository Number One
## Owner of this repository. Used in gitweb list of projects.
owner = John Doe
## Allow git-daemon to publish this repository.
daemon = yes
## Allow gitweb to show this repository.
gitweb = yes

[repo projekt/projektrepo-eins]
description = Repository for our project
owner = John Doe
daemon = yes
gitweb = yes

[repo private]
description = Private repository
owner = John Doe
daemon = no
gitweb = no

[repo projekt/projektrepo-private]
description = Another repository for our project
owner = John Doe
daemon = no
gitweb = no

Auch das sollte eigentlich selbsterklärend sein. Zu beachten ist, daß die Angaben unter “daemon” und “gitweb” nur steuern, ob gitosis eine entsprechende “magische” Datei git-daemon-export-ok für git-daemon anlegt bzw. das Repository in eine Projektdatei für gitweb aufnimmt. Ob die entsprechenden mit “yes” gekennzeichneten Repositories dann via gitweb oder git-daemon auch wirklich verfügbar sind (und vor allem die mit “no” gekennzeichneten nicht!), ist eine Frage der Konfiguration dieser beiden Programme.

Nunmehr müssen für die in der gitosis.conf definierten Benutzer noch jeweils deren öffentliche SSH-Key hinterlegt werden, und zwar in keydir, wobei für jeden Nutzer eine Datei mit dem Namen $nutzername.pub angelegt werden muß, die mindestens einen Schlüssel enthalten muß, aber auch mehrere Schlüssel enthalten darf. Der oder die Schlüssel des Nutzers “me@my.host.example” gehören also in die Datei me@my.host.example.pub.

Schließlich müssen die Dateien mit dem Schlüsseln mittels git add hinzugefügt und alle Änderungen mittes git commit -a committed werden; danach wird das Repository mittels git push an gitosis verfüttert. Voilà!

2. git-daemon

git-daemon ist recht einfach zu installieren:

aptitude install git-daemon-run

git-daemon-run verwendet allerdings nicht die gewohnten Scripts in /etc/init.d, sondern runit/runsv, so dass sich ein Symlink lohnt:

ln -s /usr/bin/sv /etc/init.d/git-daemon

Außerdem sollte /etc/sv/git-daemon/run noch entsprechend konfiguriert werden:

#!/bin/sh
exec 2>&1
echo ‘git-daemon starting.’
exec chpst -ugitdaemon /usr/lib/git-core/git-daemon --verbose --enable=upload-pack --enable=upload-archive --base-path=/home/gitosis/repositories /home/gitosis/repositories

Statt “-ugitdaemon” wäre ggf. bei neueren Versionen des gitosis-Pakets in Debian “-ugitosis” zu verwenden; der Pfad /home/gitosis/repositories ist (zweimal) ggf. durch den Pfad zu den in gitosis angelegten Repositories zu ersetzen, im Falle des Debian-Paketes standardmäßig /srv/gitosis (den Grund für meine diesbezügliche Änderung habe ich weiter oben beschrieben).

Schließlich muß man sich noch entscheiden, welche Services der git-daemon bieten soll. “upload-pack” erlaubt den Zugriff via git fetch, git pull und git clone, “upload-archive” die Verwendung von git archive.

Das sollte es dann gewesen sein.

3. gitweb

Das gitweb-Paket aus Debian Lenny kann gleichfalls in wenigen Schritten installiert und konfiguriert werden; danach ist nur noch der Webserver - in meinem Fall Apache 2.2 - entsprechend anzupassen, wobei ich für gitweb einen eigenen vhost aufgesetzt habe.

a) gitweb

aptitude install gitweb

Dann kommt die /etc/gitweb.conf an die Reihe:

# path to git projects (<project>.git)
#$projectroot = “/var/cache/git”;
$projectroot = “/home/gitosis/repositories/”;

# directory to use for temp files
$git_temp = “/tmp”;

# target of the home link on top of all pages
#$home_link = $my_uri || “/”;

# html text to include at home page
$home_text = “indextext.html”;

# file with project list; by default, simply scan the projectroot dir.
# $projects_list = $projectroot;

# Point to projects.list file generated by gitosis.
$projects_list = “/home/gitosis/gitosis/projects.list”;

# stylesheet to use
$stylesheet = “/gitweb.css”;

# logo to use
$logo = “/git-logo.png”;

# the ‘favicon’
$favicon = “/git-favicon.png”;

# A list of base urls where all the repositories can be cloned from.
# Easier than having per-repository cloneurl files.
@git_base_url_list = (’git://git.host.example’);

“$projectroot” ist hier der Pfad zu den von gitosis angelegten Repositories, standardmäßig /srv/gitosis/repositories; “$projects_list” umfasst die Repositories, die gitweb anzeigen soll, und ist entweder ein Verzeichnis (bspw. $projectroot), in dem die Repositories liegen, oder eine Datei mit einer Liste der Repositories. Wenn man hier die Funktionalität von gitosis nutzen will, in der gitosis.conf zu steuern, welche Repositories gitweb anzeigen soll, dann ist es wichtig, hier auf die von gitosis erzeugte Projektliste zu verweisen, wie im obigen Beispiel geschehen! Wenn man sicherstellen will, daß gitweb nicht nur die Anzeige der Repositories auf die in der Liste gezeigten beschränkt, sondern auch nur diese Repositories überhaupt zum Abruf über das Webinterface anbietet, muß die Konfiguration hier noch um

$strict_export = “true”;

ergänzt werden. Schließlich können noch allgemeine Parameter wie “@git_base_url_list” gesetzt werden.

b) apache2

Für den Webserver konfiguriere ich, wie einleitend beschrieben, einen eigenen vhost in /etc/apache2/sites-available/gitweb:

<VirtualHost *:80>
 ServerName git.host.example
 ServerAdmin webmaster@host.example

 HeaderName HEADER

 # bogus but safe DocumentRoot
 DocumentRoot /var/cache/git

 #Alias /robots.txt /var/www/cvs.robots.txt
 Alias /gitweb.css /usr/share/gitweb/gitweb.css
 Alias /git-favicon.png /usr/share/gitweb/git-favicon.png
 Alias /git-logo.png /usr/share/gitweb/git-logo.png
 ScriptAlias / /usr/lib/cgi-bin/gitweb.cgi
</VirtualHost>

Ich füge außerdem den Benutzer www-data, unter dem der Apache-Webserver läuft, noch in /etc/group zur Gruppe gitosis hinzu, damit er die Repositories lesen kann.

Danach aktiviere ich den zuvor angelegten vhost:

a2ensite gitweb
/etc/init.d/apache2 reload

Jetzt sollte unter http://git.host.example/ das Webinterface von gitweb mit den freigegebenen - und befüllten! - Repositories auftauchen.

Fertig!

Patches für control-archive

thh@inter.net (Thomas Hochstein) — Tue, 12 Jan 2010 22:53:00 +0100

Ich hatte ja bereits darüber berichtet, daß mich der simple Wunsch, meinen Newsserver etwas aufzuräumen, über den Umweg über die List of Usenet public managed hierarchies auf eine mehrwöchige Tour durch die deutschsprachigen Regionalhierarchien geschickt, zum Aufbau von De-Regio und zur Installation von git gebracht hatte. Mittlerweile habe ich mich hinreichend sortiert, um für das control-archive-Paket eine ganze Reihe von Änderungen einzureichen, die ich nun in Form von git-Patches gebracht und per Mail an den Maintainer verschickt habe; mehr oder weniger das erste Mal, daß ich auf diese Weise irgendwo einen Beitrag leiste. Mal schauen, ob die Patches akzeptiert werden.

Mit git muß ich mich aber definitiv noch näher beschäftigen, sofern es da auch etwas unter Windows gibt; das scheint mir endlich mal ein VCS zu sein, mit dem ich klarkomme.

git

thh@inter.net (Thomas Hochstein) — Sun, 03 Jan 2010 20:51:00 +0100

Nein, nicht “igitt”! Git. (iGit wäre vermutlich die Apple-Variante.)

Nachdem gestern Russ Albery auf meine Frage, in welchem Format denn Änderungen für das control.ctl (siehe dazu auch meinen vorigen Beitrag) am besten eingereicht werden sollten, mit

Anyone who’s really inspired can send me Git patches against the repository at git://git.eyrie.org/usenet/control.git, of course.

geantwortet hatte, war mein Ehrgeiz geweckt; schließlich plane ich nach Abschluss meiner “Forschungen” über die deutschsprachigen Regionalhierarchien eine Zusammenstellung der dann vermutlich eher umfangreichen Änderungen einzureichen, und warum sollte ich das dann nicht direkt richtig professionell versuchen? Außerdem wollte ich mich seit Jahren immer schon mal wieder mit Versionsverwaltungssystemen beschäftigen, bin aber bisher nie über die eher theoretischen Konzepte - konkret von SVN - herausgekommen. Warum also nicht jetzt einen neuen Versuch wagen?

Daher habe ich etwas gegoogelt, mir git heruntergeladen (naja, genauer gesagt das passende Debian-Paket git-core installiert), das Repository ausgecheckt und festgestellt, daß das eigentlich eine recht einfache Sache zu sein scheint. Mal gucken, wie ich dann auch tatsächlich damit zurechtkomme. Bevor es soweit ist, dürften ja auch noch einige Recherchen anstehen (und der Versuch, die Ergebnisse praktikabel zusammenzustellen und zu präsentieren; meine erste Idee, eine statische HTML-Seite zu bauen, hat sich jedenfalls eindeutig nicht bewährt).