Netz - Rettung - Recht

Vergangenes Wochenende hatte ich von der diesjährigen Mitgliederversammlung von bawue.net berichtet und dabei auch meiner Hoffnung Ausdruck gegeben, vielleicht die eine oder andere dort aufgeschnappte - teils schon ältere - Idee doch bald einmal ausprobieren zu können. Heimlich gehofft hatte ich dabei auf einen Test eines VPN von meinem Laptop aus - soweit bin ich allerdings (noch) nicht. Jedoch hatte ich dort gefühlt bei jedem zweiten Teilnehmer ein Smartphone gesehen und die Gelegenheit genutzt, mich einmal zu erkundigen, was die Dinger denn so können und wofür man sie wirklich benutzen kann. Schließlich frage ich mich schon länger, ob es sich für mich wohl lohnen würde, doch vergleichsweise viel Geld in die Hand zu nehmen, um ein iPhone, Samsung, Nexus oder was auch immer zu erwerben. Die Antworten waren vielfältig (E-Mails lesen, Reise-/Routenplaner, SSH-Client, Tethering für den Laptop; auch ein tolles Spiel, bei dem man Flugzeuge koordiniert auf Landebahnen befördern muß, wurde als "Killerapplikation" genannt), so recht überzeugt war ich von dem wirklichen Nutzen aber noch nicht. Immerhin trage ich meist auch meinen Laptop mit mir herum, habe dafür inzwischen eine brauchbare UMTS-Karte gefunden, und wer weiß, was man auf einem so kleinen Bildschirm und ggf. ohne echte Tastatur sinnvoll tun kann?

Nun kam aber inzwischen dazu, daß ich mir auch Twitter mal angesehen habe, und der channelansässige Hardwareproll mir bedeutete, Twittern ohne "mobile device" sei auf Dauer nicht so richtig zielführend. Überdies war ich letztes Wochenende - und den Großteil der Woche - krank und dementsprechend als empfindliches männliches Wesen Szaf natürlich sehr trostbedürftig. Also habe ich - nach Einholung einiger Informationen zu Modellen und Tarifen - einfach mal eine größere Menge Geld in die Hand genommen und mir ein HTC Desire zugelegt. Zurückschicken kann man es ja immer noch, nicht wahr?

Und mittlerweile muß ich sagen, ich weiß gar nicht, wie ich bisher ohne ausgekommen bin.

Ich telefoniere zwar immer noch mit meinem bisherigen, nunmehr schon etliche Jahre alten Modell, aber es ist einfach toll, auch unterwegs mal eben nach neuen E-Mails schauen zu können, Kalender und Kontakte dabei zu haben und synchronisieren zu können, zu twittern oder schnell mal was im Web nachzusehen, sich dank GPS und GoogleMaps jederzeit orientieren zu können, und was der Dinge mehr sind. Natürlich habe ich auch ein paar Spiele getestet - und die Geschichte mit den Flugzeuglandungen hat definitiv Suchtcharakter. Auch die Akku-Laufzeit ist - wenn man mit der Nutzung ein bißchen sparsam ist und GPS und WiFi ausschaltet, solange man es nicht braucht bzw. unterwegs ist - mit "problemlos ein Arbeitstag" durchaus im brauchbaren Bereich.

Insofern lautet mein vorläufiges Fazit nach weniger als einer Woche: Das hätte ich mir schon früher gönnen sollen!

In einem Posting in de.admin.news.groups hatte Simon Paquet in einem Nebensatz angesprochen, daß Cornell Binders wunderbare graphische Usenet-Statistiken seit über einem halben Jahr nicht mehr aktualisiert worden sind, wozu letzterer dann erklärte, daß ihm seine bisherige Datenquelle seit September 2009 abhanden gekommen war. Nach einem kurzen Mailwechsel habe ich mich dann abends noch hingesetzt und auf die Schnelle ein Script zusammengepfuscht, das zumindest von jetzt an die notwendigen Rohdaten - wie viele Postings in welche de.*-Newsgroups gepostet werden - live aus dem Feed von news.szaf.org in einer Datenbank erfaßt, so daß spätestens ab Mai wieder entsprechende Statistiken zur Verfügung stehen sollten.

Um die Lücken der vergangenen Monate nach Möglichkeit zu füllen habe ich dann über Nacht - zweimal - ein weiteres Script über den gesamten vorhandenen Newsspool laufen lassen, das für jedes Posting die Header (Kopfzeilen) prüft und, wenn das Posting (auch) in eine de.*-Newsgroup gerichtet war, Newsgroups- und Message-ID-Header und den Timestamp aus der History des Newsservers in eine Logdatei schreibt. Der betreffenden Maschine wurde dabei einigermaßen warm unter der Wolle, wie man auch noch in der nivellierten Wochendarstellung sieht (die Drehzahl des CPU-Lüfters war in der "Live"-Darstellung weit über den Gehäuselüfter hinausgeschossen), aber nach einigen Stunden Laufzeit (genau genommen: am nächsten Morgen) stand mir dann eine Textdatei mit pro Zeile allen notwendigen Angaben über jeweils ein Posting zur Verfügung, die ich dann auf dieselbe Art und Weise wie bei der Live-Statistik in eine Datenbank extrahiert habe. Die daraus generierten Statistiken geben - bei allen Abweichungen, die insbesondere bei solchen rückwärtigen Auswertungen nicht zu vermeiden sind - die tatsächlichen Verhältnisse einigermaßen brauchbar wieder, wie einige einfache Plausibilitätstests ergeben haben Leider waren die Daten für den 1. und 2. September 2009 unvollständig (der erste Tag fehlte praktisch ganz, der zweite teilweise), so daß ich erst ab Oktober 2009 Daten nachliefern konnte und im September einstweilen eine Lücke bleibt. Die nachgelieferten Daten wurden aber mittlerweile immerhin schon eingespielt, so daß die Usenet-Statistiken jetzt wieder auf dem aktuellen Stand sind.

Die erzeugten Daten aus dem April habe ich unter Löschen von Duplikaten in die Live-Datenbank eingespielt, so daß diese jetzt die vollständigen Daten ab dem 01.04.2010 enthält und zukünftig jeweils zeitnah zum Monatsende die notwendigen Daten geliefert werden können. Dabei werden alle Postings erfaßt, die auch in mindestens eine de.*-Newsgroup gehen und keine Steuernachrichtnen sind (so daß Cancel ignoriert, Supersedes aber erfaßt werden, was dem entspricht, was man tatsächlich in der Newsgroup auch "sieht"); bei Crossposts wird das betreffende Posting in jeder Newsgroup gezählt, in der es erscheint. Das führt zwar bei den summierten Zahlen für de.ALL und die entsprechenden Teilhierarchien ggf. zu falsch hohen Zahlen, gibt aber den Zustand der jeweils einzelnen Newsgroups am besten wieder.

Sicherlich sind insoweit noch Verbesserungen möglich - und geplant -, aber das wird bis zu einem anderen Mal warten müssen.

Bereits seit etlichen Jahren poste ich nicht nur meine eigenen FAQs automatisiert ins Usenet, sondern biete das auch für andere Interessenten an. In letzter Zeit wurden die noch gepflegten und zu postenden FAQs immer weniger; die verbliebenen habe ich jetzt von auto-faq auf das 0.7er-Release von yapfaq umgestellt.

Sehr angenehm daran ist unter anderem, daß ich jetzt nicht mehr für jede zu postende FAQ einen eigenen Crontab-Eintrag brauche, sondern nur noch einen (täglichen) für alle FAQs, der dann die jeweils anstehenden Postings - und nur diese - auslöst. Die dadurch minimal kleinere Flexibilität - es lassen sich bestimmte Wochentage nur noch indirekt (durch das Datum des ersten Postings) festlegen und bestimmte Sonderwünsche (zweimal pro Monat, am 14. und 28., o.ä.) nicht mehr umsetzen - nehme ich gerne für den verminderten Aufwand in Kauf.

Soweit die FAQs einen Last-Modified:-Pseudo-Header haben, erspare ich mir überdies bei Änderungen des FAQ-Textes auch die (sonst ggf. zusätzlich anfallende) Änderung des Subject:-Headers in der Konfiguration (und das spricht sehr dafür, den FAQs, die noch keinen solchen Header haben, ggf. einen zu verpassen oder durch den Maintainer verpassen zu lassen).

Wenn also noch jemand FAQs zu posten hat: jetzt wieder gerne jederzeit her damit!

Dieser Text ist überholt und nicht mehr aktuell. Eine aktuelle Anleitung für die Installation von git for Windows, dem Nachfolger von msysgit, zusammen mit plink aus dem Putty-Paket findet sich auf meinen Webseiten.

---

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.

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.

Dieser Text ist überholt und nicht mehr aktuell. Eine aktuelle Anleitung für die Installation von git for Windows, dem Nachfolger von msysgit, zusammen mit plink aus dem Putty-Paket findet sich auf meinen Webseiten.

---

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.

Meine Mailserver erwarten, daß derjenige, der eine E-Mail einliefern möchte, sich ordnungsgemäß "vorstellt" (also ein einigermaßen korrektes HELO bzw. EHLO überträgt, namentlich nicht den - respektive einen der - Namen meiner eigenen Maschinen und auch keine bloße IP-Adresse). Normalerweise fängt dieser vergleichsweise "weiche" Filter nicht viel Spam weg (und "härter" filtern, bspw. überprüfen, ob die Vorwärts-Rückwarts-Auflösung stimmt o.ä., möchte ich darauf nicht).

In den letzten Tagen hat sich allerdings namentlich eine Maschine aus Venezuela geradezu rührend bemüht, trotzdem E-Mail loszuwerden:

root@host:~# zgrep -c wonderl.com /var/log/exim/mainlog.*
/var/log/exim/mainlog.01:32569
/var/log/exim/mainlog.02.gz:133069
/var/log/exim/mainlog.03.gz:164318
/var/log/exim/mainlog.04.gz:161655
/var/log/exim/mainlog.05.gz:142325

Das sind gestern rund 32.500 Versuche, und die vier Tage zuvor, mithin über Ostern, jeweils deutlich über 100.000. Ich würde ja gerne wissen, ob das immer dieselbe E-Mail sein sollte (nachdem die Versuche in der Regel maximal im Sekundenabstand liegen, liegt das allerdings eher fern), oder ob mir da massiv Spam erspart geblieben ist … Jedenfalls eine durchaus bemerkenswerte Penetranz, die dort an den Tag gelegt wurde.

Seit Jahren - und nicht nur im übertragenen Sinne, sondern tatsächlich seit ungefähr 2005 - verwundert und stört es mich, daß insbesondere die Startseite dieses meines Blogs hier sehr langsam lädt; "langsam" im Sinne von "der Aufruf dauert oft mehrere Sekunden". Ich habe abwechselnd das teilweise tabellenbasierte Layout, teilweise die Datenbankabfragen verantwortlich gemacht, bin aber nie so recht zu einer Lösung gelangt, obwohl ich schonmal die Vermutung hatte, daß möglicherweise die Tabellenstruktur von Serendipity - dem besten Blog der Welt - etwas durcheinandergeraten ist oder irgendwo noch ein Index fehlt. Solche und ähnliche Probleme tauchten vor Jahren schon einmal auf; entweder fehlte da etwas in einer uralten Version, oder ich habe mal einen Fehler bei der Installation gemacht; und da ich das Blog seitdem immer durch Neuinstallation gefolgt von einem Ersetzen der Datenbank durch die Sicherungskopie der alten Datenbank umziehe, bleiben solche Fehler einfach erhalten.

Wie ich dieser Tage beim Durchgehen alter Newsgroupbeiträge feststellte, habe ich das Thema Ende 2006 (!) schon einmal in szaf.* angesprochen, den Tip erhalten, doch einfach mal im MySQL-Daemon das Logging von "slow queries" zu aktivieren. Schon im Februar vergangenen Jahres habe ich diesen Rat dann auch umgesetzt und erfahren, daß ich mir dann diese Queries einfach mal angucken und dann mittels EXPLAIN näher untersuchen soll. Aber dann kamen andere Aufgaben dazwischen, ich hatte - wie üblich - nicht ausreichend Zeit, und das Thema geriet schon wieder in Vergessenheit.

"Mein Blog ist (nicht mehr) langsam" vollständig lesen

Viele werden Nagios, das Monitoringsystem, kennen, manche werden es auch nutzen. Für die letzteren mag nagstamon eine hilfreiche Ergänzung darstellen: ein kleines Icon im Systray oder als "schwebende" Statusleiste auf dem Desktop, das entweder in knallgrün "OK" verkündet oder einen Warnton von sich gibt und die Farbe nach gelb, rot oder schwarz wechselt, wenn Systeme ausgefallen sind. Im letzteren Fall läßt sich durch Deuten mit dem Mauszeiger ein Panel ausklappen, auf dem die Nagios-Warnungen dargestellt werden und weitere Informationen abrufbar sind. So hat man den Status seiner Systeme immer übersichtlich dargestellt und im Falle eines Falles alle notwendigen Informationen zur Hand.

nagstamon kann mehrere Nagios-Server abrufen und erhält seine Informationen durch regelmäßiges Polling (Standard: minütlich) der status.cgi-Seite der jeweiligen Nagios-Installation.

Wem nagstamon nicht zusagt, dem gefällt stattdessen vielleicht ein vergleichbares Firefox-Plugin, das ähnliche Arbeit leistet.

Dieser Tage stellte ich fest, daß mein Heimserver die letzten Wochen sein Backup nicht per FTP auf die Sicherungsplatte schieben konnte. Nachdem ich am Freitagabend mal wieder in den früher heimischen Gefilden weilte, wollte ich das Problem schnell mal beheben. Allerdings scheiterte der Einstieg in die Problembehebung schon daran, daß mein Laptop zwar das WLAN fand, aber keine IP-Adresse zugeteilt bekam. Das Problem gibt es manchmal, also habe ich halt den Desktoprechner hochgefahren, um von da aus mal auf die Servermaschine zu gucken. Der kam allerdings auch nicht richtig hoch, sondern brauchte sehr lange für den Boot … was daran lag, daß er auch keine IP-Adresse bekam.

Also habe ich mal den Monitor "am Gerät" angeknipst und festgestellt, daß der Server korrekt lief, aber keinerlei DCHP-Einträge im Log sind. Offenbar ist also das Problem mit der Netzwerkverkabelung viel schlimmer als befürchtet: nicht nur, daß der Server selbst keine funktionsfähige Netzwerkverbindung mehr hat (seit dem letzten Ausfall ist er durch lose durch die Räume verlegtes Kabel angebunden), sondern jetzt sind offenbar auch die anderen Kabel angeknackst.

Eine gute halbe Stunde und mehr später bin ich ratlos: egal welche provisorische Verkabelungen ich durch die Gegend ziehe, es wird nicht besser - DHCP-Verkehr kommt einfach nicht am Server an, das Logfile bleibt leer. Dabei hatte ich den DHCP-Server sogar restartet. Auch ein erneuter Restart ändert nichts, produziert noch nicht einmal Logeinträge. Was an und für sich ja komisch ist. Und irgendwie läuft auch kein DHCP-Server. Genau genommen finde ich auch gar keinen DHCP-Server …

"Die meiste Arbeit macht man sich selbst" vollständig lesen

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:

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.

Wie am Wochenende schon angekündigt, habe ich yapfaq in den letzten Tagen etwas weiterbearbeitet. Version 0.6 (bzw., aufgrund einiger kleiner Fehler im ersten Release, Version 0.6.2) enthält neben einigen kleineren Änderungen vor allem folgende Erweiterungen:

Variabler Expires:-Header

Die bisherige Version hat einen Expires:-Header von drei Monaten gesetzt; dieser Wert ist nunmehr konfigurierbar.

Kommandozeilen-Parameter

yapfaq nimmt jetzt einige Kommandozeilen-Parameter entgegen. So können mittels "-v" Informationen über den Programmablauf ausgegeben werden; mit dem Parameter "-f" kann die Abarbeitung auf die genannte FAQ beschränkt werden, yapfaq arbeitet dann also nicht alle FAQs ab. Außerdem kann mit "-p" das Posten aller - oder einer - FAQ(s) erzwungen werden, auch wenn diese eigentlich noch nicht fällig ist; am sinnvollsten ist das im Zusammenhang mit "-f". Die Parameter "-d" und "-t" ermöglichen Tests: "-d" führt zu einem reinen Simulationslauf, bei dem nichts gepostet wird, so daß bspw. getestet werden kann, welche FAQs zum Posten anstehen würden. "-t" ermöglicht es, die FAQ nicht in die eigentlich vorgesehene(n) Gruppe(n) zu posten, sondern stattdessen in eine Testgruppe oder auf die Konsole auszugeben, um zu prüfen, wie ein Posting aussehen würde.

Die aktuelle Version steht jeweils auf meiner Downloadseite zur Verfügung.

Perl bietet eine recht interessante und bequeme Art, die Dokumentation zu einem Script oder Modul in den Programmcode einzubetten: POD, "plain old documentation".

Dieses Format ermöglicht es, die Dokumentation jeweils beim Code einzubetten oder doch zumindest am Ende des Programmcodes in derselben Datei zu speichern. Diese Dokumentation kann dann mittels perldoc angezeigt oder mit Hilfe von entsprechenden Tools in andere Formate - Klartext, HTML, man pages etc. - konvertiert werden, so daß die Dokumentation aus dem Sourcecode selbst erzeugt werden kann.

Mehr Informationen dazu:

• perlpod man page
• perldoc man page
• podlators (translators from POD to text and nroff from Russ Allbery)
• pod2text man page
• pod2html man page
  

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.

"Was mir an git gefällt" vollständig lesen

Dieser Text ist überholt und nicht mehr aktuell. Ich nutze bereits seit Mitte 2010 TortoiseGit nicht mehr. Eine Anleitung für die Installation von git for Windows, dem Nachfolger von msysgit, zusammen mit plink aus dem Putty-Paket findet sich auf meinen Webseiten.

---

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.

Es gibt eine ganze Reihe von Lösungen, um FAQs automatisiert und regelmäßig ins Usenet zu posten:

Zum einen kann man dafür auto-faq von Ian Kluft und Paul W. Schleck nutzen, ein Perl-Script, das ich seit Ende der Neunziger für das automatische Posten diverser FAQs verwende. Es besteht aus einer Konfigurationsdatei, in der für jede FAQ definiert wird, wie sie nach wo gepostet wird. Die einzelnen FAQs sind als Textdateien abgelegt, über die Konfigurationsdatei werden die einzelnen Header und Pseudo-Header festgelegt; Message-IDs, Expires:- und Supersedes:-Header werden automatisch erzeugt. Gepostet werden die FAQs, deren Namen bei Aufruf des Scripts übergeben werden; das läßt sich via cron automatisieren, wobei für jede FAQ ein eigener crontab-Eintrag benötigt wird. auto-faq bietet einen ganzen Haufen an Optionen, hat aber den Nachteil, zum Posten zwingend inews - aus dem INN-Paket - oder vergleichbare Tools zu verwenden; außerdem bietet es eine Unzahl von Funktionen, namentlich auch zum Posten vielteiliger FAQs, die aber - jedenfalls für mich - keine Relevanz hatten. Und auto-faq wurde 1992 entwickelt und hat seit 1999, also seit über 10 Jahren, keine Änderung mehr erfahren …

Eine Alternative dazu stellt postfaq von Russ Allbery dar, gleichfalls in Perl implementiert. postfaq verfolgt ein anderes Konzept: hinterlegt in einer Textdatei wird hier nicht nur der Body der FAQs, sondern das komplette Posting einschließlich aller Headerzeilen. Konsequenterweise wird eine gesonderte Konfigurationsdatei nicht benötigt. Auch postfaq erzeugt die notwendigen Headerzeilen und postet die beim Aufruf angegebenen FAQs, was via cron automatisiert werden kann; es benötigt dazu aber keine externen Programme wie inews o.ä. Es wird aktiv gepflegt (letzte Änderung 2008).

Und eine weitere Möglichkeit ist yapfaq ("yet another postfaq"), ein Script von Marc Brockschmidt, das ich vor etlichen Jahren bereits einmal angetestet hatte, jetzt aber nirgendwo mehr wiedergefunden habe. Marc war aber dankenswerterweise so nett, mir die aktuelle Version (letzte Änderung: Februar 2003) zu überlassen; ich plane, yapfaq noch ein wenig für meine Zwecke zu bearbeiten und weiter zu entwickeln, as time permits. Einstweilen steht yapfaq über ein Git-Repository zur Verfügung.

yapfaq arbeitet grundsätzlich vergleichbar zu auto-faq: in einer zentralen Konfigurationsdatei wird definiert, welche FAQs in welchen Abständen wohin gepostet werden sollen. Die einzelnen FAQs sind als Textdateien abgelegt, wobei die Header durch das Script beim Posten gesetzt und ergänzt werden. Im Unterschied zu auto-faq postet yapfaq aber nicht nur eine bestimme FAQ, sondern alle FAQs, die "dran" sind, die also zuletzt vor - mindestens - dem definierten Zeitraum gepostet wurden. Es ist also nicht notwendig, für jede FAQ einen eigenen crontab-Eintrag zu definieren; vielmehr kann man yapfaq einfach täglich aufrufen, und jede FAQ wird dann gepostet, soweit sie "fällig" ist.