L’interopérabilité Git avec un référentiel Mercurial

Mise à jour de juin 2012. À l’heure actuelle, les méthodes d’interopérabilité Git / Hg semblent être les suivantes:

1. Installez Mercurial et l’ extension hg-git . Vous pouvez le faire en utilisant votre gestionnaire de paquets ou avec easy_install hg-git . Ensuite, assurez-vous que ce qui suit est dans votre ~ / .hgrc:

    [extensions] hggit = 

   Vous pouvez voir quelques références qui parlent de spécifier l’extension de bookmarks ici aussi, mais qui a été intégrée à Mercurial depuis la version 1.8. Voici quelques conseils sur l’installation de hg-git sous Windows .

   Une fois que vous avez hg-git, vous pouvez utiliser les commandes à peu près comme Abderrahim Kitouni ci-dessus . Cette méthode a été affinée et modifiée depuis 2009, et il existe un wrapper convivial: git-hg-again . Cela utilise le répertoire toplevel comme répertoire de travail pour Mercurial et Git en même temps. Il crée un signet Mercurial qu’il synchronise avec la pointe de la twig default (non nommée) dans le référentiel Mercurial et met à jour une twig Git locale à partir de ce signet.

2. git-remote-hg est un wrapper différent, également basé sur l’extension Mercurial hg-git . Cela utilise en outre les protocoles git-remote-helpers (d’où son nom). Il utilise le répertoire toplevel uniquement pour un répertoire de travail Git; il garde son repository Mercurial à nu. Il maintient également un deuxième repository Git nu pour rendre la synchronisation entre Git et Mercurial plus sûre et plus idiomatique.

3. Le script git-hg (anciennement géré ici ) utilise une méthode différente, basée sur hg-fast-export du projet d’exportation rapide . Comme la méthode 2, cela permet également de conserver un référentiel Mercurial dénudé et un référentiel Git nu supplémentaire.

   Pour tirer, cet outil ignore les signets Mercurial et importe à la place chaque twig Mercurial nommée dans une twig Git et la twig Mercurial par défaut (non nommée) dans une twig.

   Certains commentaires traitent de cet outil comme étant hg-> git uniquement, mais il prétend avoir fusionné dans le support push de git-> hg le 7 décembre 2011. Comme je l’explique dans une revue de ces outils , la façon dont cet outil tente de l’implémenter le support push ne semble pas être réalisable.

4. Il y a aussi un autre projet appelé git-remote-hg . Contrairement à la version ci-dessus, celle-ci ne repose pas sur hg-git, mais accède directement à l’API Mercurial Python. Pour le moment, son utilisation nécessite également une version corrigée de git. Je n’ai pas encore essayé ça.

5. Enfin, Tailor est un projet qui convertit progressivement une variété de VCS différents. Il semblerait que le développement de ce système ne se poursuivra pas de manière agressive.

Les trois premières approches semblaient assez légères pour me convaincre d’enquêter. J’avais besoin de les peaufiner pour qu’ils s’exécutent sur mon installation, et j’ai vu quelques moyens de les améliorer pour les améliorer, puis je les ai encore peaufinés pour les rendre plus semblables les uns aux autres pour que je puisse évaluer eux plus efficacement. Ensuite, j’ai pensé que les autres aimeraient aussi avoir ces ajustements pour faire la même évaluation. J’ai donc créé un paquet source qui vous permettra d’installer mes versions de l’un des trois premiers outils. Il devrait également prendre en charge l’installation hg-fast-export pièces nécessaires à l’ hg-fast-export . (Vous devez installer hg-git par vous-même.)

Je vous encourage à les essayer et à décider vous-même de ce qui fonctionne le mieux. Je serais ravi d’entendre parler de cas où ces outils se brisent. Je vais essayer de les garder en phase avec les modifications en amont et de m’assurer que les auteurs en amont sont au courant des modifications que je pense utiles.

Comme je l’ai mentionné ci-dessus, en évaluant ces outils, je suis arrivé à la conclusion que git-hg n’est utilisable que pour tirer de Mercurial, pas pour pousser.

Dans le même ordre d’idées, voici quelques manuels de comparaisons / traductions utiles entre Git et Mercurial, parfois destinés aux utilisateurs qui connaissent déjà Git:

• Mercurial pour les utilisateurs de Git
• Git et Mercurial – Comparer et Contraste
• Quelle est la différence entre Mercurial et Git
• Mercurial et Git: une comparaison technique
• Pierre git hg rosetta
• Codage Homebrew: Mercurial
• Blog de Francisoud: Git vs Mercurial (hg)
• Git vs Mercurial

Il y a un nouveau git-remote-hg qui fournit un support natif:

Support de pont à Git pour Mercurial et Bazaar

Copiez simplement git-remote-hg dans votre $ PATH, rendez-le exécutable, et c’est tout, pas de dépendances (autres que Mercurial):

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

Vous devriez être capable de tirer et d’en tirer comme s’il s’agissait d’un repository Git natif.

Lorsque vous poussez de nouvelles twigs Git, les favoris Mercurial seront créés pour eux.

Voir le wiki git-remote-hg pour plus d’informations.

Vous devriez pouvoir utiliser hg-git .

 hg clone  

éditez ~/.hgrc et ajoutez:

 [extensions] hgext.bookmarks = hggit = 

créer un signet pour avoir un master en git:

 cd  hg bookmark -r default master 

éditez .hg/hgrc dans le repository et ajoutez:

 [git] intree = true 

maintenant vous pouvez créer le repository git:

 hg gexport 

et vous pouvez utiliser le répertoire résultant en tant que clone git. tirer de mercurial serait:

 hg pull hg gexport 

et en poussant à mercurial:

 hg gimport hg push 

(Oui, vous devez utiliser hg avec ce stream de travail, mais votre piratage sera entièrement git)

PS Si vous avez un problème avec ce stream de travail, veuillez déposer un bogue.

Vous pouvez essayer hg2git , qui est un script python et qui fait partie de l’export rapide, que vous pouvez trouver sur http://repo.or.cz/w/fast-export.git .

Vous devez toutefois installer mercurial.

Comme hg-git est un pont à deux voies, il vous permettra également de transmettre les modifications de Git à Mercurial.

Hg-Git Mercurial Plugin . Je n’ai pas essayé moi-même, mais pourrait être intéressant de vérifier.

J’ai eu un grand succès avec git-hg de https://github.com/cosmin/git-hg (nécessite également l’installation de hg ). Il supporte le fetch, le pull et le push et est plus stable pour moi que le hg-git (fonctionnalités similaires de hg à git).

Voir https://github.com/cosmin/git-hg#usage pour des exemples d’utilisation. L’interface utilisateur est très similaire à git-svn .

Le git-hg nécessite un espace disque supplémentaire pour chaque référentiel hg cloné. L’implémentation utilise un clone mercurial complet, un clone supplémentaire git supplémentaire et le repository git réel. L’espace disque requirejs est environ 3 fois supérieur à l’utilisation normale de git. Les copies supplémentaires sont stockées sous le répertoire .git de votre répertoire de travail (ou de l’emplacement désigné par GIT_DIR comme d’habitude).

Remarque: Le problème de base que git-hg tente de résoudre est qu’il n’y a pas de mappage 1: 1 entre les fonctionnalités git et hg . Le plus gros problème est la non-concordance d’impédance entre les twigs git et les twigs non nommées hg et les twigs nommées hg et hg (toutes ressemblent beaucoup aux twigs pour les utilisateurs git ). Un problème connexe est que hg essaie d’enregistrer le nom de la twig nommée d’origine dans l’historique de la version, par opposition à git, où le nom de la twig est ajouté uniquement au message de validation du modèle par défaut.

Tout outil qui prétend créer un pont interopérable entre git et hg devrait expliquer comment il va gérer cette correspondance d’impédance. Vous pouvez ensuite décider si la solution sélectionnée correspond à vos besoins.

La solution git-hg consiste à supprimer tous les signets hg et à convertir les twigs nommées en twigs git. En outre, la twig principale de git est définie par défaut sur la twig hg sans nom.

J’ai essayé le hggit. Fonctionne pour moi, car je dois faire face au travail des git’ers et des hg’ers. Surtout pour les critiques c’est super.

Un problème / avertissement mineur sur ce sujet:

J’ai essayé de cloner un repository de kernel Linux stable avec hg. Ces référentiels sont maintenus dans git et contiennent généralement un grand nombre de fichiers.

C’était très lent. Il m’a fallu 2 jours pour cloner complètement et mettre à jour une copie de travail.

J’ai essayé git-hg de cosmin et git-hg-again de abourget à la fois sur le repo hg de mutt , il semble que plus le respect de l’ordre de fusion se fasse plus tard, le premier est un peu aléatoire. Vous pouvez voir sur les captures d’écran ci-dessous.

Un graphe d’historique de fusion de mutt importé par git-hg de cosmin :

Un graphique d’historique de fusion de mutt importé par git-hg-again de abourget :

Le graphe de l’historique actuall, tracé par hgk sur le référentiel hg de mutt:

Comme vous pouvez le voir ci-dessus, le second graphique de git-hg-again de abourget est très proche du graphe de hgk original et reflète en fait le stream de travail réel du mutt.

Un inconvénient de git-hg-again que j’ai trouvé est qu’il n’ajoute pas de télécommande “hg”, mais importe plutôt toutes ses références en tant que balises locales, git-hg a une merveilleuse télécommande “hg” qui représente le repo hg en amont.

La synchronisation bidirectionnelle hg-git (et git-git, hg-hg) est également possible avec le service Git-hg Mirror . Il utilise hg-git (entre autres) en coulisse et son code est également open source.

Disclaimer : Je suis de la société derrière cela.