Fryboyter

Mercurial - Mehrere Commits zu einem Commit zusammenfügen

Nehmen wir an, dass man in einem lokalen Mercurial-Repository mehrere kleine Commits erstellt hat. Nun will man nicht jeden dieser Commits pushen, sondern aus mehreren kleinen Commits vorher einen größeren Commit erstellen.

Gehen wir von folgendem fiktiven Beispiel aus.

hg log -v -l 2
Änderung:        408:f5a5d6c7d965
Lesezeichen:     main
Marke:           tip
Nutzer:          Fryboyter <hg@fryboyter.de>
Datum:           Sun Jul 31 15:47:53 2022 +0200
Dateien:         README.md
Zusammenfassung: Fügt einen Text hinzu

Änderung:        407:6d5f6ac48ddb
Nutzer:          Fryboyter <hg@fryboyter.de>
Datum:           Sun Jul 31 15:47:31 2022 +0200
Dateien:         README.md
Zusammenfassung: Fügt eine Überschrift hinzu

Wie man sieht, beziehen sich die letzten beiden Commits auf einfache Änderungen in der gleichen Datei für die ein Commit gereicht hätte. Also machen wir doch einfach aus den zwei Commits einen einzelnen Commit.

Hierfür habe ich mich für histedit entschieden. Hierbei handelt es sich nicht um ein externes Plugin wie hg-git, sondern um eine Funktion die Mercurial von Haus aus bietet. Diese muss man allerdings erst aktivieren. Hierfür reicht es aus in der Konfigurationsdatei hgrc unter [extensions] histedit = einzutragen. Also beispielsweise wie folgt.

[extensions]
hggit = ~/repository/hg-git/hggit
histedit =

Will man nun beispielsweise die beiden letzten Commits zusammenfuegen, führt man den Befehl hg histedit -r -2. Nun sollte man eine Anzeige, ähnlich der folgenden erhalten.

?: help, k/up: move up, j/down: move down, space: select, v: view patch   
d: drop, e: edit, f: fold, m: mess, p: pick, r: roll
pgup/K: move patch up, pgdn/J: move patch down, c: commit, q: abort
Older commits are shown above newer commits.
  #0  pick   407:6d5f6ac48ddb   407 Fügt eine Überschrift hinzu
  #1  pick   408:f5a5d6c7d965   408 Fügt einen Text hinzu

changeset: 408:f5a5d6c7d965
user:      Fryboyter <hg@fryboyter.de>
bookmark:  main
summary:   Fügt einen Text hinzu
files:     README.md
no overlap

Wir möchten nun, dass Commit #1 Teil von Commit #0 wird, sodass wir diesen pushen können. Hierfür wählen wir den Commit #1 aus und drücken auf der Tastatur f. In der betreffenden Zeile sollte anstelle von pick nun ^fold angezeigt werden. Abschließend drücken wir auf der Tastatur noch c. Nun ändert man die Commit-Nachricht ab und speichert sie.

Führt man nun hg log -v -r 2 aus, sollte der Commit #1 nicht mehr angezeigt werden und beim Commit #0 sollte die neue Commit-Nachricht angezeigt werden. Führt man hg diff -c tip aus, sollte der Commit auch beide Änderungen enthalten. Bei “tip” handelt es sich übrigens um den letzten vorhandenen Commit.

OSBN

Mercurial - Lokale Änderungen in zweites lokales Repository übertragen

Ab und zu beginne ich damit, Änderungen in einem lokalen Mercurial Repository durchzuführen und werde damit nicht fertig. In der Regel mache ich dann später einfach weiter und nutze dafür den gleichen Rechner. Ab und zu möchte ich aber lieber mit einem anderen Rechner weiterarbeiten. Zum Beispiel mit meinem Notebook auf dem Sofa.

Wie nun am besten die lokalen Änderungen von Rechner A auf Rechner B übertragen?

Am einfachsten wäre es wohl, einen Commit über die unfertigen Änderungen zu erstellen, diesen bei beispielsweise Github hochzuladen und dann auf Rechner B das Arbeitsverzeichnis dammit zu aktualisieren. Ich vermeide aber möglichst solche Work in Progress Commits.

Das Repository mit Tools wie Syncthing von einem Rechner auf den anderen übertragen? Das klappt bei Repositories wohl in der Regel. Aber es gibt auch schon einige negativen Erfahrungen. Wohl hauptsächlich mit den Verzeichnissen wie .git oder .hg in denen unter anderem die Historie gespeichert ist. Ein zusätzliches bare Repository zu nutzen wäre vermutlich eine Alternative.

Da ich den Anwendungsfall aber nur sehr habe, habe ich mich für eine andere Lösung entschieden. Im Arbeitsverzeichnis des Repositories in dem ich mit den Änderungen begonnen habe, erstelle ich mittels hg diff > patch.diff einen Patch über die vorhandenen Änderungen. Diesen Patch spiele ich dann im zweiten Repository mittels hg import –no-commit patch.diff ein. Wichtig ist hierbei den Parameter –no-commit zu nutzen, da sonst für die Änderungen ein Commit erstellt wird, was ich ja erst einmal vermeiden will bis ich wirklich fertig bin.

Das mag nun nicht die beste Lösung sein. Und vielleicht kann man es mit einer anderen Versionsverwaltung (die ich nicht nutzen will) einfacher lösen. Aber für mich ist es erst einmal ausreichend.

OSBN | VCS

Github mit Mercurial nutzen

Vor ein oder zwei Wochen habe ich mir eines meiner Git-Repository zerlegt. Da mich die Lösung viel Zeit, zu viele Nerven und zwei Commits gekostet hat, bin ich nun wieder bei Mercurial gelandet. Dieses Werkzeug mag zwar nicht so mächtig wie Git sein, die Fehlermeldungen sowie die Dokumentation sind meiner Meinung nach viel besser verständlich.

Allerdings will ich auch weiterhin Github aufgrund dessen weiter Verbreitung nutzen. Sei es nun um dort selbst etwas zu veröffentlichen oder um mich an Projekten Dritter zu beteiligen. Mercurial bietet hierfür ein Plugin, dass sich Hg-Git nennt. Damit kann man ein Git-Repository herunterladen und es wird lokal automatisch in ein Mercurial-Repository umgewandelt. Nimmt man nun Änderungen vor, werden diese dann vor dem Hochladen in ein Git-Repository so geändert, dass sie mit Git kompatibel sind. Die Einrichtung von Hg-Git ist zudem ziemlich einfach.

Ich gehe bei folgender Anleitung davon aus, dass sowohl Mercurial als auch python-dulwich auf dem Rechner installiert ist und das im Home-Verzeichnis das Verzeichnis Projekte existiert. Dem Verzeichnis kann man natürlich einen anderen Namen geben.

Zuerst wechselt man im Terminal Emulator seiner Wahl in das Verzeichnis Projekte und lädt dort die Dateien von Hg-Git herunter.

cd ~/Projekte
hg clone https://foss.heptapod.net/mercurial/hg-git hg-git

Alternativ kann man Hg-Git auch über die Paketverwaltung seiner Distribution installieren.

Als nächstes erweitert man die Datei .hgrc im Home-Verzeichnis um folgenden Inhalt. Falls die Datei noch nicht vorhanden ist, einfach anlegen und die drei Zeilen eintragen.

[extensions]
hgext.bookmarks =
hggit = ~/Projekte/hg-git/hggit

Zeile zwei aktiviert das Plugin Bookmarks das in diesem Fall Branches simuliert. Zeile drei aktiviert das eben heruntergeladene Plugin Hg-Git.

Im Verzeichnis Projekte laden wir nun mit folgendem Befehl ein Git-Repository herunter (die Github-Adresse sowie das Zielverzeichnis fryboyter.git bitte entsprechend an die eigenen Gegebenheiten anpassen).

hg clone git@github.com:Fryboyter/Hugo.git fryboyter.hg

Da hierbei von Git zu Merurial umgewandelt wird, kann dies je nach Größe des Repository etwas dauern.

Als Nächstes wechselt man in das Verzeichnis in dem das nun erstellete Mercurial-Respository liegt. In diesem Beispiel also fryboyter.hg. Dort führt man abschließend noch den Befehl hg bookmark -f main aus. Anstelle von main muss man die Bezeichnung des Haupt-Branch angeben. Ansonsten erkennt Mercurial bei einem Push keine Änderungen.

Nun sollte alles funktionieren. Bei meinen Tests konnte ich zumindest problemlos von Github pullen und zu Github pushen. Mehr brauche ich in meinem Fall eigentlich auch nicht. Was mir bei der ganzen Aktion aufgefallen ist, dass das lokale Mercurial-Repository weniger als 30 MB groß ist. Das lokale Git-Repository hingegen belegt etwas mehr als 60 MB. Davon geht die Welt jetzt nicht unter aber es ist trotzdem ein interessantes Detail.

OSBN | Allgemein

Heptapod - Gitlab mit Unterstützung von Mercurial

Bei Heptapod handelt es sich um eine Plattform zur Versionsverwaltung ähnlich Github. Im Gegensatz zu Github basiert diese allerdings auf Gitlab und unterstützt dank der Entwickler auch Mercurial. Vor ein paar Jahren hatte ich bereits in einem Artikel, bei dem es um die Einstellung der Unterstützung von Mercurial bei Bitbucket ging, schon einmal auf Heptapod hingewiesen. Damals war die Plattform allerdings noch neu und unfertig.

Da ich vor ein paar Tagen mir ein Git-Repository zerschossen habe (Layer-8-Problem) und mich die Lösung viel Zeit und Nerven gekostet hat, habe ich mich mal wieder im Bereich der Versionsverwaltung Mercurial umgesehen. Heptapod gibt es immer noch und inzwischen ist es auch öffentlich nutzbar. Neben heptapod.host was hauptsächlich für Unternehmen gedacht ist, gibt es auch noch das kostenlose Angebot https://foss.heptapod.net/public, das sich an FOSS-Projekt wendet.

Wer selbst hosten will, findet alle nötigen Informationen unter https://heptapod.net/pages/get-heptapod.html#get-heptapod.

Intern werde ich vermutlich wieder auf Mercurial wechseln. Git ist mir zu mächtig und zu kompliziert. Zudem finde ich die Dokumentation von Mercurial deutlich besser.

Aufgrund der weiten Verbreitung werde ich aber auch weiterhin Github nutzen, da es hierfür inzwischen funktionierende Lösungen gibt. Aber das ist ein Thema für einen weiteren Artikel.

OSBN | Allgemein

Bitbucket verabschiedet sich von Mercurial

Wer als Versionsverwaltung Mercurial verwendet und diese nicht selbst hosten will nutzt vermutlich meist das Angebot von Bitbucket.

Auf dem offiziellen Blog wurde nun bekannt gegeben, dass in einigen Monaten die Unterstützung für Mercurial eingestellt wird. Bitbucket setzt dann wie andere Anbieter (z. B. Github oder Gitlab) nur noch auf Git.

Ab dem 01. Februar 2020 kann man bei Bitbucket keine Mercurial-Repositories anlegen. Ab dem 01. Juni 2020 ist dann endgültig Schluss und die vorhandenen Repositories werden gelöscht.

Wer also Projekte bei Bitbucket hostet, sollte bis spätestens 31. Mai seine Daten sichern und sich nach einer Alternative umsehen.

Ich vermute die Entscheidung von Bitbucket wird dazu führen, dass einige Projekte nun zu Git wechseln.

Wer weiterhin Mercurial nutzen will, kann sich https://www.mercurial-scm.org/wiki/MercurialHosting ansehen. Dort werden einige alternative Anbieter (die mich auf den ersten Blick alle nicht beigeistern) aufgeführt.

Ebenfalls werden dort Möglichkeiten zum selber hosten genannt. Hier finde ich vor allem Heptapod interessant. Hierbei handelt es sich um einen Fork von Gitlab der Mercurial unterstützt. Zudem sind die Entwickler von Gitlab dem Fork positiv gesinnt und unterstützen die Entwicklung. Laut den Entwicklern ist Heptapod allerdings noch in einem frühen Entwicklungsphase. Wer also Mercurial für wichtige Projekte nutzt, sollte daher noch abwarten.

OSBN | Allgemein