Letzte Änderung am 24. Februar 2022 by Christoph Jüngling
Ich möchte ein Repository von Mercurial nach Git transformieren. Dazu gibt es zwei Anlässe: Erstens möchte ich einige Projekte in Zukunft unter Git weiter führen. Zweitens möchte ich wiederum einige Projekte zu einem anderen Anbieter umziehen. Und der “versteht” leider kein Mercurial, sondern nur Git.
Das Konvertieren von Hg nach Git ist im Grunde nicht so schwer, da Git dafür bereits einen eingebauten Mechanismus besitzt: git clone hg::quelle ziel. Man beachte bitte den doppelten Doppelpunkt, das ist kein Schreibfehler!
Wenn ich jedoch nicht nur den Quellcode, sondern auch die umliegenden Informationen eines Cloudanbieters wie Wiki und Issue Tracker in den Umzug einschließen will, wird es etwas aufwändiger.
In diesem Artikel
Butter bei die Fische
Konkret geht es um den Anbieter Bitbucket (Atlassian) und das Projekt VB and VBA Code Library, hier detailliert beschrieben. Dort habe ich im Sommer 2011 meinen ersten Commit hochgeladen. Damals habe ich noch mit Mercurial gearbeitet, über das ich hier ja auch schon recht viel geschrieben habe.
Wenn ich nun auf Git umstelle, soll das nicht heißen, dass Mercurial schlecht ist. Es hat meiner Ansicht nach durchaus seine Stärken (insbesondere die Hg-Workbench, die einfach großartig ist!), und die Lernkurve ist bei Mercurial vielleicht nicht so steil wie bei Git. Und es hat, das kann man nicht oft genug sagen, eine bemerkenswert gute und übersichtliche Workbench!
Aber da der Trend deutlich erkennbar in Richtung Git geht, musste ich mich auch damit beschäftigen. Zur Vorgehensweise sei kurz das Konzept geschildert, bevor wir in medias res gehen.
Auf Bitbucket alles in ein neues temporäres Projekt importieren, dabei das Quellcode-Repository nach Git konvertieren:
- Hg-Repository in lokales Git-Repository clonen
- Wiki-Repository in lokales Repository clonen
- Issue-Tracker exportieren
- Temporäres Projekt mit “Git” als Quellcodeverwaltung anlegen
- Neuen “Remote” für das temporäre Projekt in lokalem Git-Repository hinzufügen
- “git push” zum neuen Remote ausführen
- Issue-Tracker-Export in temporäres Projekt importieren
- Neuen “Remote” für das Wiki des temporären Projekts in lokalem Repository hinzufügen
- Lokales Wiki-Repository zu neuem Remote pushen
Auf Gitlab das Projekt importieren:
- Den Import aus dem temporären Projekt von Bitbucket anstoßen (das dauert u.U. ein paar Minuten)
- Ergebnis überprüfen (Commit Logs, Wiki, Issue-Tracker)
Auf Bitbucket aufräumen:
- Temporäres Projekt auf Bitbucket löschen
- Bei Bedarf das alte Projekt auf Bitbucket ebenfalls löschen und dabei die URL des Projektes auf Gitlab als Umzugsadresse angeben (dient zukünftigen Besuchern als Weiterleitung)
Projektstrukturen lokal sichern
Wie gesagt, ginge es nur um den Quellcode, wäre die Sache schnell erledigt, auch mit Historie (siehe oben). Leider ist das reine Hg-Repository nicht das einzige. In dem obigen Projekt habe ich z.B. auch den Issue-Tracker und das Wiki benutzt. Diese Informationen möchte ich natürlich nicht verlieren.
Damit haben wir unsere Todo-Liste:
- Quellcode
- Wiki
- Issues
Quellcode
Dies geht — zumindest auf meinem Linux-Rechner (für Windows siehe hier) — in einem Schritt (vorher in ein passendes Verzeichnis wechseln):
git clone hg::ssh://hg@bitbucket.org/juengling/vb-and-vba-code-library
Das dauert nicht lange, denn das Repository ist nicht allzu groß. Im Ergebnis erhalten wir ein lokales Verzeichnis mit dem gleichen Namen wie das Projekt auf Bitbucket. Im Grunde haben wir nun ein lokales Git-Repository, das mit dem Remote-Mercurial-Repository verbunden ist, wie ein einfacher Befehl zeigt:
$ git remote -v origin hg::ssh://hg@bitbucket.org/juengling/vb-and-vba-code-library (fetch) origin hg::ssh://hg@bitbucket.org/juengling/vb-and-vba-code-library (push)
Damit könnten wir nun lokal mit Git arbeiten, während das Mercurial-Repository auf dem Bitbucket-Server weiterhin unverändert allen anderen da draußen zur Verfügung steht. Wiki und Issue-Tracker können wie gewohnt benutzt werden, auch die Meta-Kommandos wie fixes issue #42 usw. funktionieren weiterhin, denn aus der Sicht von Bitbucket sind es ja “nur” Texte in den Commit-Messages.
Wem das schon reicht, der kann hier aussteigen :-)
Wiki und Issue-Tracker
Da das Wiki ebenfalls ein Mercurial-Repository ist, können wir das fast auf die gleiche Weise behandeln:
$ git clone hg::ssh://hg@bitbucket.org/juengling/vb-and-vba-code-library/wiki vb-vba-wiki
Für den Issue-Tracker gehen wir zu “Einstellungen / Tickets / Import & Export”, klicken auf “Export starten” und laden das Ergebnis herunter.
Temporäres Projekt anlegen
Die Umstellung nach Git muss noch auf Bitbucket durchgeführt werden, da das Projekt sonst nicht von Gitlab importiert werden kann. Dazu müssen wir ein zusätzliches Projekt auf Bitbucket anlegen. Dieses erhält den Code aus dem lokalen Git-Repository, Issues und Wiki werden 1:1 übernommen.
Der Name dieses Projektes ist beliebig, es wird ohnehin nicht lange existieren. Nennen wir es “vb-vba-temp”. Als “Version control system” wählen wir “Git”, und unter “Erweiterte Einstellungen” aktivieren wir “Ticket-Verfolgung” und “Wiki”.
Quellcode hochladen
Den Anweisungen unter “I have an existing project” folgen wir im Prinzip, allerdings mit kleinen Abweichungen. Die Remote-Einstellung “origin” existiert bereits von unserem ersten clone, daher wähle ich hier der Einfachheit halber “neworigin”. Und der Push-Befehl bekommt --all angefügt, wodurch alle Branches und alle Tags gepusht werden.
git remote add neworigin git@bitbucket.org:juengling/vb-wiki.git git push neworigin --all
Im Ergebnis haben wir dann unseren Git-Quellcode in das neue Projekt hochgeladen.
Wiki und Issue-Tracker
Auch das Pushen des Wiki-Codes erfolgt fast genauso wie oben. Da Bitbucket jedoch bereits eine Beispieldatei angelegt und committet hat, brauchen wir den Zusatz --force, um diesen Commit am Ziel zu überschreiben. Der zuvor erwähnte Zusatz --all ist hier nicht notwendig, da das Wiki-Repository nur den default/master-Branch keine Tags enthält.
git remote add neworigin git@bitbucket.org:juengling/vb-vba-temp.git/wiki git push neworigin master --force
Ein erneuter Aufruf der Wiki-Seite sollte nun die alten Inhalte zeigen.
Für den Issue-Tracker gehen wir in unserem temporären Projekt ebenfalls zu “Einstellungen / Tickets / Import & Export”. Mit “Durchsuchen” und “Import starten” importieren wir dann die zuvor exportierten Tickets.
Import des Projektes nach Gitlab
Im Vergleich zu den oben beschriebenen Vorbereitungen ist dieser Schritt ausgesprochen simpel. Wir starten, indem wir ein neues Projekt anlegen. Dort befindet sich rechts oben der Reiter “Import project”, der sodann eine Anbieterauswahl zeigt. Ein Klick auf “Bitbucket” listet nach Eingabe der Zugangsdaten die importierbaren Projekte auf. Dies sind alle Projekte, die unter Bitbucket bereits mit Git angelegt wurden. Dies ist der Grund für die aufwendigen Vorarbeiten!
Vorher können wir zwecks besserer Wiedererkennung in der zweiten Spalte noch den shreklichen* Namen “vb-vba-temp” in den Namen des Originalprojektes umändern.
Jetzt ist das Glück nur noch eine Träne* einen Klick entfernt :-)
Nacharbeiten in Gitlab
Leider ist im konkreten Fall etwas schiefgegangen. Als Markup-Sprache hatte ich im Bitbucket-Projekt “Creole” ausgewählt. Dies versteht Gitlab leider nicht, daher sieht das importierte Wiki ein wenig seltsam aus. Wenn das Wiki nicht allzu umfangreich ist, bietet sich natürlich eine manuelle Umarbeitung nach “Markdown” an. Das wird auch der Weg sein, den ich in diesem konkreten Fall gehen werde.
Aber was, wenn nicht? Ein naheliegender Gedanke wäre Pandoc, das ziemlich umfangreiche Konvertierungen ermöglicht. Doch leider bringt der folgende Befehl nicht das gewünschte Ergebnis, sondern die Fehlermeldung “pandoc: Unknown reader: creole”:
pandoc -f creole -t markdown Home.wiki -o Home2.wiki
Vielleicht werde ich dieses Problem irgendwann einmal angehen. Für den Anfang mag es genug sein.
Nacharbeiten in Bitbucket
Nach der erfolgreichen Übernahme nach Gitlab können wir zunächst das temporäre Projekt in Bitbucket löschen (“Einstellungen / Transfer or delete repository”). Ein “Redirect Link” ist hierbei nicht erforderlich.
Wenn man will, kann dann auch das Original-Repository gelöscht werden, wobei dort ein “Redirect Link” durchaus sinnvoll wäre. Dieser sollte auf das neue Repository bei Gitlab zeigen, damit alle Besucher, die noch über den alten Link verfügen, dorthin umgeleitet werden.
Ich für meinen Teil werde allerdings das Projekt beibehalten, jedoch Wiki und Issue-Tracker deaktivieren und eine Readme-Datei mit einem entsprechenden Hinweis einfügen.
- Kleine Hommage an Shrek 2 :-)
Neueste Kommentare