seeseekey.net - Invictus Deus Ex Machina

Manchmal möchte man Git-Repository in einer bestimmten Art strukturieren. So will man unter Umständen mehrere Repositories logisch zu einem Repository gesellen. Dafür gibt es unter Git Submodule. Gegeben sei folgende Repositorystruktur:

Framework
Library1
Library2
Library3

Möchte man die Bibliotheken Library1, Library2 und Library3 logisch in das Repository Framework einbinden, kann man die Submodule nutzen. Dazu geht man in das Repository Framework und fügt die andere Repositories als Submodule hinzu:

git submodule add git@example.org:Library1
git submodule add git@example.org:Library2
git submodule add git@example.org:Library3

Damit wird im Repository Framework eine Datei mit dem Namen .gitmodules angelegt, in welcher folgender Inhalt zu finden ist:

[submodule "Library1"]
	path = Library1
	url = git@example.org:Library1

[submodule "Library2"]
	path = Library2
	url = git@example.org:Library2

[submodule "Library3"]
	path = Library3
	url = git@example.org:Library3

Diese Datei kann dann per Commit dem Repository hinzugefügt werden. Beim klonen eines solchen Repositories, muss man nur darauf achten das es rekursiv geklont und gepullt (git submodule foreach git pull) wird, damit die Submodule ebenfalls aktualisiert werden.

Der Commodore 64 verfügte über ein ROM, in welchem das BASIC und der KERNAL gespeichert wurden. Michael Steil digitalisierte das komplette dokumentierte ROM des C64er aus dem Buch Das neue Commodore-64-intern-Buch und stellt sie neben einigen anderen in einem Git-Repository auf GitHub zur Verfügung.

Das kommentierte ROM in der HTML Version

Neben der Version aus dem Git-Repository gibt es das ganze auch als HTML-Seite auf pagetable.com. Dort sind die deutsche Version und auch der originale Quelltext von Microsoft, sowie englische ROM-Kommentare zu finden.

Auf Plattformen wie GitHub ist es ganz einfach bestehende Projekte zu forken, sie bei sich weiterzuentwickeln und die Änderungen an das Original-Projekt zurückzugeben. Ein klein wenig komplizierter ist es das geforkte Git-Repository wieder vom Original aus zu aktualisieren. Im ersten Schritt muss dabei im geforkten Repository ein Upstream definiert werden. Dies geschieht im Terminal mit dem Befehl (in diesem Falle auf GitHub bezogen):

git remote add upstream https://github.com/ORIGINAL_OWNER/ORIGINAL_REPOSITORY.git

Mittels des Befehls git remote –v kann anschließend überprüft werden ob der Eintrag vorgenommen wurde. Nun können die Änderungen vom Remote upstream in das lokale Git-Repository mittels:

git pull upstream master

übernommen werden. Anschließend kann man das ganze noch mittels git push auf den entfernten Server übertragen.

Der Titel dieses Artikels, könnte den Leser glauben lassen, das es in diesem Artikel um ein Skript geht, welches irgendwelche Vorteile bei schlechten Netzwerkverbindungen bringt. Allerdings ist das Gegenteil der Fall. Bei dem in Go geschriebenen Tool mit dem Namen Comcast handelt es sich um ein Skript zur Simulation eines schlechten Netzwerkes.

Comcast auf GitHub

Comcast soll dabei helfen Anwendungen zu testen, welche Netzwerkfunktionalitäten nutzen. So kann man überprüfen das die Anwendungen auch unter schlechten Bedingungen funktionieren (und falls dies nicht der Fall ist nacharbeiten). Das Skript läuft unter Linux, Mac OS X sowie BSD-Systemen. Der Quelltext der unter der Apache-Lizenz stehenden Software ist auf GitHub zu finden.

Microsoft kauft Mojang und damit Minecraft. Wenn man sich andere Akquisitionen von Microsoft im Spielebereich anschaut, bekommt man bei dieser Vorstellung ein mulmiges Gefühl. Entweder Sie fahren das Spiel gegen die Wand, oder es läuft demnächst nur noch auf Microsoft-Betriebssystemen. Natürlich kann auch alles funktionierten und unsere Befürchtungen erweisen sich als gegenstandslos. Allerdings zeigt der Aufkauf von Mojang eine Abhängigkeit auf. So haben viele Menschen riesige Bauwerke geschaffen, welche unter Umständen bald nicht mehr verfügbar sind. Minecraft ist nicht nur ein Spiel, es ist ein Kreativbetriebssystem. In einem solchem Fall spielt freie Software ihre Vorteile aus. Bei einer solchen Software, kann man das ganze einfach forken und in seinem Sinne weiterentwickeln. Bei proprietärer Software wird dies schwierig.

Eine von vielen Minecraft-Welten

Mit Minetest gibt es einen durch Minecraft inspirierten Clone, welcher für Mac OS X, Linux und Windows verfügbar ist. Das Spiel ist im Gegensatz zur aktuellen Minecraft-Version etwas rudimentär, was Dinge wie verfügbare Blöcke und ähnliches angeht. Allerdings relativiert sich das ganze wenn man sich die API-Schnittstelle anschaut. Mit Hilfe der API, kann man alle möglichen Erweiterungen wie Loren, TNT, Mobs oder Pyramiden ins Spiel holen. Die maximale Weltgröße ist auf −30912 zu 30927 in allen Dimensionen (auch Z) beschränkt. Etwas seltsam erscheint mir allerdings die Speicherung der Map in einer SQLite-Datenbank — dort muss sich zeigen ob dies bei großen Welten wirklich performant ist. Auch für Server-Backups ist dieses Verfahren nicht wirklich gut geeignet. Minetest ist in C++ entwickelt, was sich positiv auf die allgemeine Performance auswirkt, so das es auch auf schwächeren Rechnern genutzt werden kann — so gibt es schon Versuche das ganze auch auf dem Raspberry Pi zum laufen zu bringen.

Minetest in Aktion

Die Entwicklung von Minetest sieht dabei vielversprechend aus, so das man in Zukunft viele Verbesserungen und neue Features erwarten darf. Neben dem Client ist auch ein Server für den Mehrspieler-Betrieb verfügbar. Der unter der LGPL lizenzierte Quellcode kann über GitHub bezogen werden. Die offizielle Seite von Minetest ist unter minetest.net zu finden.

Wer in das Versionskontrollsystem Git einsteigen möchte, aber keine Lust hat ein Tutorial nach dem anderen durchzuprobieren, sollte es mal mit try.github.io versuchen. Dabei handelt es sich um ein von GitHub zur Verfügung gestelltes interaktives Tutorial in 25 Schritten.

try.github.io

Dabei wird man Stück für Stück in die Git Befehle eingeführt und kann das live am angezeigten Octobox Repository ausprobieren. Das ganze Tutorial sollte dabei in etwa 15 — 30 Minuten in Anspruch nehmen.

Möchte man einen Git Branch entfernen, so ist dies auf der Konsole mit einer Zeile erledigt:

git branch -D alterBranch

Unter TortoiseGit, einer freien Git Integration für Windows ist dies etwas komplizierter, da das ganze etwas versteckt ist. Um einen Branch zu löschen, öffnet man mittels des Kontextmenüs den Switch/Checkout-Dialog. Dort klickt man auf den Button mit den drei Punkten.

Switch/Checkout

Anschließend öffnet sich ein Dialog welcher eine Übersicht über alle Repository-Branches anzeigt. Dort kann der gewünscht Branch mittels Kontextmenü gelöscht werden.

Manchmal möchte man einen Remote-Tag unter Git wieder entfernen bzw. ihn komplett löschen. Dazu dienen folgende Kommandos:

git tag -d tagToBeRemoved
git push origin :refs/tags/tagToBeRemoved

Im ersten Schritt wird der Tag lokal entfernt. Anschließend wird die Änderung in das Remote-Repository übertragen. Damit ist der Tag Geschichte und sollte nicht mehr auftauchen.

Unter Git möchte man manchmal ein Verzeichnis von einem Repository zu einem anderen verschieben. Natürlich soll dabei die Revisionsgeschichte nicht verloren gehen. In diesem Fall hilft folgendes Bashskript:

#!/bin/sh
# moves a folder from one git repository to another
# moveFolder <absolute repository one path> <repository one folder> <absolute repository two path>

# prepare repository one
cd $1
git clean -f -d -x
git checkout -b tmpBranch
git filter-branch --subdirectory-filter $2 HEAD
mkdir $2
mv * $2
git add .
git commit -a -m "Move files into folder"

#import in repository two
cd $3
git remote add repositoryOne $1
git pull repositoryOne tmpBranch
git remote rm repositoryOne

#cleanup
cd $1
git checkout master
git branch -D tmpBranch

#remove folder with history from repository one
cd $1
git filter-branch -f --index-filter "git rm -rf --cached --ignore-unmatch $2" HEAD

Genutzt wird das Skript dabei wie folgt:

./moveFolder /absolute/path/to/repo/one folderFromRepoOne /absolute/path/to/repo/two

Nachdem das Verzeichnis in das neue Repository mitsamt der Revisionsgeschichte übertragen wurde, wird es aus dem alten Repository entfernt. Das Skript funktioniert dabei unter Windows, Linux und Mac OS X. Die jeweils aktuellste Version ist auf GitHub zu finden.

Nachdem ich versuchte Git per WebDAV in Verbindung mit ownCloud einzurichten, fiel mir ein, das die größeren Paketen (ab Premium) bei all-inkl.com auch einen SSH Zugang beinhalten. Mit diesem ist es relativ einfach das Webhosting Paket als Server für Git Repositories zu benutzen. Sollte auf dem lokalen Rechner noch kein SSH-Schlüssel erzeugt worden sein, so kann dies mittels:

ssh-keygen -t rsa -C "seeseekey@example.org"

nachgeholt werden. Nun kann der Schlüssel an den all-inkl Server übertragen werden:

ssh-copy-id -i ~/.ssh/id_rsa.pub ssh-nutzername@example.org

Anschließend ist es möglich sich mit dem all-inkl SSH Server ohne Authentifikation über ein Passwort anzumelden:

ssh ssh-nutzername@example.org

Dort legen wir in dem Ordner in welchem unserer Git Repository landen soll ein leeres Repository an:

git init --bare

Als nächsten Schritt trägt man einen Remote an ein lokales Git Repository an:

git remote add origin ssh://ssh-nutzername@example.org/www/htdocs/nutzername/repos/Example.git

Danach kann das lokale Repository mit dem Befehl:

git push origin master

auf den entfernten Server kopiert werden. Benötigt man es auf einem anderen Rechner so kann das ganze mittels:

git clone ssh://ssh-nutzername@example.org/www/htdocs/nutzername/repos/Example.git

bewerkstelligt werden.