Fryboyter

Git zu Mercurial konvertieren

Oft kommt es vor, dass jemand von einer Versionsverwaltung zu Git wechselt. Ab und zu kommt es aber auch vor, dass jemand von Git auf eine andere Lösung wechseln will. Kürzlich hatte ich solch eine Anfrage. Gewünscht war Mercurial.

Das betreffende Git-Repository war noch recht frisch aber es gab bereits Commits im niedrigen dreistelligen Bereich. Zu viele um diese in Mercurial manuell anzulegen.

Was aber gar nicht nötig ist. Mercurial bietet die Möglichkeit der Konvertierung an.

Nehmen wir einmal an im Home-Verzeichnis gibt es das Verzeichnis repository. In diesem befindet sich das Verzeichnis blog.git in welchem das Git-Repository vorhanden ist.

Als erstes erzeugt man im Verzeichnis repository das Unterverzeichnis blog.hg und welchselt in dieses. Dort erzeugt man dann mittels “hg init” ein Mercurial-Repository. Hierbei wird das Verzeichnis .hg erstellt. In diesem erzeugt man die Datei hgrc mit folgendem Inhalt.

[extensions]
hgext.convert=

Hiermit aktiviert man die Erweiterung mit der man die Konvertierung vornehmen kann.

Nun führt man im Verzeichnis blog.hg folgenden Befehl aus.

hg convert --datesort ~/repository/blog.git ~/repository/blog.hg

Das ganze dauert dann etwas. Aber wenn alles geklappt hat, sollte man ein Mercurial-Repository mit allen Commits, Dateien usw. wie im Git-Repository erhalten. Sieht man sich das Verzeichnis blog.hg an, sieht man allerdings weiterhin nur das Unterverzeichnis .hg. Das Problem behebt man in dem man den Befehl “hg update” ausführt. Sieht man sich danach das Verzeichnis blog.hg an sieht man auch die ganzen Dateien die man ursprünglich zum Git-Repository hinzugefügt hat.

OSBN | Allgemein

Fryboyter wird nun mit Hugo erzeugt

Bisher habe ich für fryboyter.de das CMS Bolt verwendet. Im Grunde bin ich damit auch zufrieden. Aber irgendwie habe ich in letzter Zeit immer weniger Lust die Updates zu installieren.

Daher habe ich mir in den letzten Wochen diverse Tools angesehen, mit denen man statische Webseiten erstellen kann. Man braucht also kein PHP, keine Datenbank usw. Somit entfällt auch das nervige Updaten der Seite.

Schlussendlich bin ich bei Hugo gelandet. Das hat im Grunde zwei Gründe. Zum einen besteht Hugo nur aus einer Datei und zum anderen werden die statischen Seiten sehr schnell erzeugt.

Was mich aber etwas beschäftigt hat war, wie ich die Seite bei neuen Artikeln möglichst einfach erzeugen und auf den Webspace hochladen kann.

Im Lab von Uberspace gibt es inzwischen eine Anleitung wie man Hugo installiert. Hierbei läuft Hugo als Dienst im Hintergrund und erzeugt die Seite neu sobald sich etwas geändert hat. Was aber zur Folge hat, dass ich mich wieder zeitnah um eventuelle Updates kümmern muss. Besser wäre es, wenn Hugo nur zum Erzeugen der Seite gestartet und danach wieder beendet wird. Das einfachste wäre es, sich per SSH mit dem Webspace zu verbinden, den neuen Artikel zu erstellen und dann Hugo manuell auszuführen. Einfach? Ja. Umständlich? Auf jeden Fall. Also kommt es auch nicht in Frage.

Die Lösung lautet, wie so oft, Git. Als erstes legt man auf dem Webspace außerhalb des Document Root ein Verzeichnis an. In diesem erzeugt man mittels “git init –bare” ein sogenannte Bare-Respository. Dies hat, im Gegensatz zu einem normalen Respository keinen Working Tree. Schaut man sich nun das Verzeichnis noch einmal an, findet man dort das Unterverzeichnis “hooks”. Mit diesen Hooks lassen sich bestimmte Dinge automatisieren. Zum Beispiel lassen sich Befehle ausführen wenn das Repository neue Daten erhalten hat. Hierfür legt man im Verzeichnis “hooks” die Datei post-receive an und befüllt diese beispielsweise wie folgt und macht diese dann noch ausführbar.

GIT_REPO=$HOME/repository/fryboyter.git
TMP_GIT_CLONE=$HOME/tmp/git/fryboyter
PUBLIC_WWW=/var/www/virtual/$USER/html/fryboyter
git clone $GIT_REPO $TMP_GIT_CLONE
~/bin/hugo -s $TMP_GIT_CLONE --cleanDestinationDir -d $PUBLIC_WWW
rm -Rf $TMP_GIT_CLONE
exit

Hiermit wird der Inhalt des Repository in ein temporäres Verzeichnis geklont. Danach löscht Hugo die bereits veröffentlichte Internetseite und erstellt diese neu. Danach wird das temporäre Verzeichnis gelöscht.

Was jetzt noch fehlt, sind die Daten mit denen man die Internetseite erzeugt. Diese erzeugt man auf dem eignene Rechner. Wenn dies erledigt ist, wechselt man in das betreffende Verzeichnis und führt folgende Befehle aus.

git init
git add .
git commit -m "Beschreibung des Commit"

Hiermit erstellt man ein lokales Repository, fügt alle Dateien des Verzeichnis hinzu und erstellt einen Commit. Läde man das ganze mittels “git push $adresse_des_repository” hoch wird automatisch die Datei post-receive ausgeführt und die Internetseite wird autoamtisch erzeugt. Um zukünftig die Seite zu aktualisieren, erzeugt / ändert man die betreffende Datei im lokalen Repository, erstellt einen neuen Commit und läd die Änderungen mittels git push hoch.

OSBN | Allgemein

Git-Version für PGKBUILD herausfinden

Im Arch User Repository, kurz AUR, gibt es einige Paket mit dem Zusatz -git im Namen. Hiermit werden nicht die stabilen Versionen sondern Entwicklerversionen installiert.

Nehmen wir einmal die PKGBUILD-Datei von keepassxc-git als Beispiel. In dieser findet man die Zeile pkgver=2.2.4.r431.g46c58b32. Egal wie oft man nun KeepassXC über diese PKGBUILD-Datei installiert, landet man immer beim gleichen festgelegten Entwicklungsstand und nicht beim derzeit aktuellen. Was aber, wenn man sich genau diesen installieren will? Im Grunde genommen muss man die Zeile pkgver= einfach nur anpassen. Aber was muss man in solch einem Fall eintragen? Eine Lösung wäre folgendes Vorgehen:

  • Mittels “git clone https://github.com/keepassxreboot/keepassxc.git” den Sourcecode auf den eigenen Rechner kopieren. Den betreffenden Link findet man in dem man auf der jeweiligen Github-Seite auf “Clone or download” klickt.

  • Danach wechselt man in das erstellte Verzeichnis. In diesem Fall keepassxc und führt dort “git describe –long | sed ’s/([^-]*-g)/r\1/;s/-/./g’” aus. Hier wird dann aktuell “2.3.0.r10.g3c274135” ausgegeben, da die Veröffentlichung von Version 2.3.0 ansteht.

  • Abschließend ändert man nun in der PKGBUILD-Datei die Zeile pkgver= entsprechend ab und kann sich so die aktuelle Entwicklerversion installieren.

  • Um die Version in der PKGBUILD-Datei erneut zu aktualisieren, reicht es in das Verzeichnis keepassxc zu wechseln und dort “git pull” und danach “git describe –long | sed ’s/([^-]*-g)/r\1/;s/-/./g” auszuführen. Git clone ist hier nicht nötig.

Da Git-Versionen aber nicht unbedingt stabil sind, sollte man aber abwägen ob man sich solch eine Version installiert oder nicht.

Linux | OSBN

Webanwendung mit git aktualisieren und Änderungen behalten

Manche meiner Webanwedungen aktualisiere ich mittels git. Bei meiner Instanz von Searx bekomme ich allerdings eine Fehlermeldung, wenn ich git pull origin master ausführe, weil ich lokal einige geänderte Dateien habe. In meinem Fall sind das Konfigurationsdateien wie settings.yml.

Da ich ehrlich gesagt keine Lust habe, hier jedes mal die Änderungen wieder auf meinem Webspace einzupflegen habe ich mal geschaut, was bei git so alles möglich ist. Bei git stash bin ich fündig geworden. Hiermit werden Änderungen an den lokalen Dateien quasi gesichert und können nach einem Update der lokalen Dateien wieder eingespielt werden.

Aktuell läuft daher die Aktualisierung von Searx daher wie folgt ab.

git stash
git pull origin master
git stash pop

Mit dem ersten Befehl lege ich mir quasi eine Kopie der Änderungen an. Mit dem zweiten Befehl spiele ich alle Änderungen seitens der Entwickler ein. Der letzte Befehl spielt dann meine Änderungen in die aktualisierten lokalen Dateien ein und löscht die Kopie wieder.

Linux | OSBN

Arch AUR nutzt ab Version 4.0 eine auf Git basierende Plattform

Gestern wurde auf der Mailing-List “arch-general” verkündet, dass ab dem 8. Juni 2015 der Umzug von AUR auf eine Plattform die auf Git basiert der Umzug startet. Wer seine Pakete weiterhin betreuen will, muss diese auf der neuen Plattform bis spätestens 07. Juli 2015 unter [aur4.archlinux.org](http://aur4.archlinux.org) einreichen. So lange werden die Pakete für die ursprünglichen Betreuer reserviert. Ab dem 8. Juli kann man unter der genannten Adresse dann die Pakete einreichen die reserviert waren aber der jeweilige Betreuer nichts gemacht hat. Am 8. August wird dann aur4.archlinux.org offiziell aur.archlinux.org ab. Änderungen an den Paketen die zwischen dem 8. Juli und dem 8. August erfolgen müssen unter aur4.archlinux.org eingereicht werden.

Eine kurze Anleitung zum Einreichen auf der neuen Plattform findet man im [Wiki](https://wiki.archlinux.org/index.php/Arch_User_Repository#AUR_4). Wer Probleme mit der neuen Platform hat, kann diese im Bugtracker melden.

Linux | OSBN