Git-Interoperabilität mit einem Mercurial Repository

Ich benutze GIT auf einem Mac. Genug gesagt. Ich habe die Werkzeuge, ich habe die Erfahrung. Und ich möchte es weiterhin verwenden. Keine Kriege hier ...

Das Problem liegt immer in der Interoperabilität. Die meisten Leute benutzen SVN, was für mich großartig ist. Git SVN funktioniert sofort und ist eine schnörkellose Lösung. Die Leute können SVN weiterhin gerne nutzen und ich verliere weder meinen Workflow noch meine Tools.

Nun ... Einige Leute kommen mit Mercurial. Gut für sie: Sie haben ihre Gründe. Aber ich kann kein sofort einsatzbereites GIT HG finden. Ich möchte nicht zu HG wechseln, muss aber trotzdem mit ihrem Repository zusammenarbeiten.

Kennt jemand von euch eine einfache Lösung dafür?

Update vom Juni 2012. Derzeit scheint es die folgenden Methoden für die Git / Hg-Interoperabilität zu geben, wenn der Entwickler von der Git-Seite aus arbeiten möchte:

1. Installieren Sie Mercurial und die hg-git-Erweiterung . Letzteres können Sie mit Ihrem Paketmanager oder mit tun easy_install hg-git. Stellen Sie dann sicher, dass Folgendes in Ihrem ~ / .hgrc enthalten ist:

   [extensions]
   hggit = 
   

   Möglicherweise sehen Sie auch hier einige Referenzen, in denen es um die Angabe der bookmarksErweiterung geht, die jedoch seit Version 1.8 in Mercurial integriert sind. Hier sind einige Tipps zur Installation von hg-git unter Windows .

   Sobald Sie hg-git haben, können Sie Befehle ungefähr wie oben beschrieben von Abderrahim Kitouni verwenden . Diese Methode wurde jedoch seit 2009 verfeinert und optimiert , und es gibt einen freundlichen Wrapper: git-hg-again . Dies verwendet das Toplevel-Verzeichnis gleichzeitig als Arbeitsverzeichnis für Mercurial und Git. Es erstellt ein Mercurial-Lesezeichen, das mit der Spitze des default(unbenannten) Zweigs im Mercurial-Repository synchronisiert ist , und aktualisiert einen lokalen Git-Zweig von diesem Lesezeichen.

2. git-remote-hg ist ein anderer Wrapper, der ebenfalls auf der Mercurial-hg-gitErweiterungbasiert. Dies nutzt zusätzlich diegit-remote-helpersProtokolle (daher der Name). Das Verzeichnis der obersten Ebene wird nur für ein Git-Arbeitsverzeichnis verwendet. Es hält sein Mercurial-Repository frei. Es unterhält auch ein zweites nacktes Git-Repository, um die Synchronisierung zwischen Git und Mercurial sicherer und idiomatischer zu machen.

3. Das git-hg- Skript (früher hier gepflegt ) verwendet eine andere Methode als hg-fast-exportdas Fast-Export-Projekt . Wie bei Methode 2 werden auch hier ein nacktes Mercurial-Repository und ein zusätzliches nacktes Git-Repository beibehalten.

   Beim Ziehen ignoriert dieses Tool Mercurial-Lesezeichen und importiert stattdessen jeden benannten Mercurial-Zweig in einen Git-Zweig und den standardmäßigen (unbenannten) Mercurial-Zweig in den Master.

   In einigen Kommentaren wird dieses Tool als nur hg-> git beschrieben, es wird jedoch behauptet, am 7. Dezember 2011 in git-> hg push support integriert worden zu sein einer Überprüfung dieser Tools , versucht dieses Tool jedoch zu implementieren Push-Unterstützung scheint nicht praktikabel zu sein.

4. Es gibt auch anderes Projekt namens git-remote-hg . Im Gegensatz zu der oben aufgeführten Version basiert diese nicht auf hg-git, sondern greift direkt auf die Mercurial Python-API zu. Zur Verwendung ist derzeit auch eine gepatchte Version von git erforderlich. Ich habe das noch nicht ausprobiert.

5. Endlich Schneider ein Projekt, das schrittweise zwischen verschiedenen VCS konvertiert. Es hört sich so an, als würde die Entwicklung nicht aggressiv fortgesetzt.

Die ersten drei dieser Ansätze sahen leicht genug aus, um mich zu einer Untersuchung zu bewegen. Ich musste sie auf einige Arten optimieren, damit sie in meinem Setup ausgeführt werden, und ich sah einige Möglichkeiten, sie weiter zu optimieren, um sie zu verbessern, und dann habe ich sie noch weiter optimiert, damit sie sich ähnlicher verhalten, damit ich sie bewerten kann sie effektiver. Dann dachte ich, andere möchten vielleicht auch diese Verbesserungen vornehmen, um die gleiche Bewertung vorzunehmen. Deshalb habe ich ein Quellpaket erstellt , mit dem Sie meine Versionen der ersten drei Tools installieren können. Es sollte sich auch um die Installation der benötigten hg-fast-exportTeile kümmern . (Sie müssen selbst installieren hg-git.)

Ich ermutige Sie, sie auszuprobieren und selbst zu entscheiden, was am besten funktioniert. Ich freue mich über Fälle, in denen diese Werkzeuge kaputt gehen. Ich werde versuchen, sie mit vorgelagerten Änderungen synchron zu halten und sicherzustellen, dass die vorgelagerten Autoren über die Verbesserungen informiert sind, die ich für nützlich halte.

Wie oben erwähnt, bin ich bei der Bewertung dieser Tools zu dem Schluss gekommen, dass git-hgnur zum Ziehen aus Mercurial und nicht zum Schieben verwendet werden kann.

In diesem Zusammenhang finden Sie einige nützliche Vergleiche / Übersetzungshandbücher zwischen Git und Mercurial, die sich in einigen Fällen an Benutzer richten, die Git bereits kennen:

• Mercurial für Git-Benutzer
• Git und Mercurial - Vergleichen und Kontrastieren
• Was ist der Unterschied zwischen Mercurial und Git
• Mercurial und Git: ein technischer Vergleich
• Git hg Rosetta Stein
• Homebrew-Codierung: Mercurial
• Francisouds Blog: Git gegen Mercurial (hg)
• Git gegen Mercurial

Es gibt eine neue git-remote-hg, die native Unterstützung bietet:

Bridge-Unterstützung in Git für Mercurial und Bazaar

Kopieren Sie einfach git-remote-hg in Ihren $ PATH, machen Sie es ausführbar und fertig, keine Abhängigkeiten (außer Mercurial):

git clone hg::https://www.mercurial-scm.org/repo/hg/

Sie sollten in der Lage sein, darauf zu schieben und zu ziehen, als wäre es ein natives Git-Repository.

Wenn Sie neue Git-Zweige verschieben, werden Mercurial-Lesezeichen für diese erstellt.

Weitere Informationen finden Sie im git-remote-hg-Wiki .

Sie sollten in der Lage sein, hg-git zu verwenden .

hg clone <hg repository>

bearbeiten ~/.hgrcund hinzufügen:

[extensions]
hgext.bookmarks =
hggit =

Erstellen Sie ein Lesezeichen, damit Sie ein masterIn-Git haben:

cd <repository>
hg bookmark -r default master

Bearbeiten Sie .hg/hgrcim Repository und fügen Sie hinzu:

[git]
intree = true

Jetzt können Sie das Git-Repository erstellen:

hg gexport

und Sie können das resultierende Verzeichnis als Git-Klon verwenden. Ziehen aus Quecksilber wäre:

hg pull
hg gexport

und auf mercurial drängen:

hg gimport
hg push

(Ja, Sie müssen hg für diesen Workflow verwenden, aber Ihr Hacking wird alles in git sein)

PS Wenn Sie ein Problem mit diesem Workflow haben, melden Sie bitte einen Fehler.

Sie können versuchen hg2git, welches Python-Skript ist und Teil des Schnellexports ist, den Sie unter http://repo.or.cz/w/fast-export.git finden .

Sie müssen jedoch mercurial installiert haben.

Da es sich bei hg-git um eine Zwei- Wege-Brücke handelt, können Sie auch Änderungssätze von Git auf Mercurial übertragen.

Hg-Git Mercurial Plugin . Ich habe es nicht selbst ausprobiert, aber es könnte sich lohnen, es mir anzusehen.

Ich habe mit großem Erfolg hatte git-hgvon https://github.com/cosmin/git-hg (erfordert den Arbeits installieren hg, auch). Es unterstützt Fetch, Pull und Push und ist für mich stabiler als hg-git(ähnliche Funktionen von hgbis Git).

Anwendungsbeispiele finden Sie unter https://github.com/cosmin/git-hg#usage . Die Benutzeroberfläche ist sehr ähnlich git-svn.

Dies git-hgerfordert zusätzlichen Speicherplatz für jedes geklonte hg-Repo. Die Implementierung verwendet einen vollständigen Quecksilberklon, einen zusätzlichen Git-Bare-Klon und das eigentliche Git-Repo. Der erforderliche Speicherplatz beträgt ungefähr das Dreifache der normalen Git-Only-Nutzung. Die zusätzlichen Kopien werden unter dem .gitVerzeichnis Ihres Arbeitsverzeichnisses (oder dem Speicherort, auf den GIT_DIRwie gewohnt verwiesen wird ) gespeichert .

Hinweis: Das grundlegende Problem, git-hgdas zu lösen versucht, besteht darin, dass zwischen gitund hgFeatures keine 1: 1-Zuordnung besteht. Das größte Problem ist die Impedanzfehlanpassung zwischen Git-Zweigen und hg-unbenannten Zweigen und hg-benannten Zweigen und hg-Lesezeichen (all diese sehen für gitBenutzer sehr nach Zweigen aus ). Ein damit verbundenes Problem besteht darin, dass hgversucht wird, den ursprünglich benannten Zweignamen im Versionsverlauf zu speichern, im Gegensatz zu git, bei dem der Zweigname standardmäßig nur zur Vorlage-Commit-Nachricht hinzugefügt wird.

Jedes Tool, das behauptet, eine interoperable Brücke zwischen diesen Impedanzanpassungen zu schaffen gitund hgzu erklären, wie es damit umgehen soll. Sie können dann entscheiden, ob die ausgewählte Lösung Ihren Anforderungen entspricht.

Die Lösung git-hgbesteht darin, alle hg-Lesezeichen zu verwerfen und benannte Zweige in Git-Zweige umzuwandeln. Außerdem wird der Git-Master-Zweig auf den unbenannten Standard-HG-Zweig gesetzt.

Habe es versucht hggit. Funktioniert für mich, da ich die Arbeit von Gitern und Hängern bewältigen muss. Besonders für Bewertungen ist dies großartig.

Ein kleines Problem / eine Warnung zu diesem Thema:

Ich habe versucht, ein stabiles Linux-Kernel-Repository mit hg zu klonen. Diese Repositorys werden in git verwaltet und enthalten normalerweise eine große Anzahl von Dateien.

Es war sehr langsam. Ich habe 2 Tage gebraucht, um eine Arbeitskopie vollständig zu klonen und zu aktualisieren.

Ich habe versucht , cosmin git-hg und abourget git-hg-wieder beide auf mutt hg Repo , so scheint es , dass die spätere Hinsicht der Ordnung einer Zusammenführung gut, die ehemaligen ein bisschen zufällig ist. Sie können aus den Screenshots unten sehen.

Ein Merge-Verlaufsdiagramm von Mutt, das von cosmins git-hg importiert wurde :

Ein Diagramm zum Zusammenführen von Kötern, das von abourgets git-hg-again importiert wurde :

Das tatsächliche Verlaufsdiagramm, das von hgk im hg-Repository von mutt aufgezeichnet wurde:

Wie Sie oben sehen können, liegt das zweite Diagramm von abourgets git-hg-again sehr nahe am ursprünglichen hgk-Diagramm und spiegelt tatsächlich den tatsächlichen Arbeitsablauf des Köter wider.

Ein Nachteil von git-hg-again, den ich gefunden habe, ist, dass es keine 'hg'-Fernbedienung hinzufügt, sondern alle seine Refs als lokale Tags importiert. Git-hg hat eine wunderbare' hg'-Fernbedienung, die das Upstream-hg-Repo darstellt.

Die bidirektionale Synchronisierung von hg-git (und git-git, hg-hg) ist auch mit dem Dienst Git-hg Mirror möglich . Es verwendet hg-git (unter anderem) hinter den Kulissen und sein Code ist auch Open Source.

Haftungsausschluss : Ich bin von der Firma dahinter.